Pete Dowson

Sorry. I know the folks at PMDG at beavering away with FSX, but what they are planning I am afraid I am not privy to! (Even if I was, which I am certainly not, I expect they'd be pretty annoyed with me if I told anyone before they were ready to say anything themselves!) Regards Pete

Martin, One thought struck me. How are you computing the "horizontal distance"? Are you making any correction for the curvature of the Earth? Obviously for small distances away from the DME station this should be negligible, but probably NDB ranges are enough for some correction to be needed at their further reaches. The altitude difference would also be affected of course -- is isn't very simple geometry. The DME distance read-out should of course be the direct slant distance. Have you tried just basing signal strength computation on that? Regards Pete

It will be a matter of rewriting stuff which is intricately involved with FS to suit FSX instead of FS2004. This is nothing whatsoever to do with FSUIPC. The PMDG aircraft only use FSUIPC for some things. They are complex designs which interact with FS directly, not external programs interfacing only via FSUIPC! I have no program which does anything like that. I think you must be mixing my program (FSUIPC) with others? They are FS gauges, written using the FS8/9 panels SDK. They are not suitable for FSX! Of course they can be re-coded. It is "merely" a programming job. I expect PMDG are already starting unless they have other priorities. But why ask me? You need to ask them! I am totally puzzled as to why you think this is a question for me? Regards Pete

Good. Thanks! That's something to do with DirectX Force Feedback. Not my field at all I'm afraid! Regards Pete

My school physics is rusty, but, yes, I think it's the inverse square law. Certainly not linear. Okay. If you do discover anything interesting please let us know! Regards Pete

Complex C-programmed gauge files like the PMDG ones can certainly cause an access violation (not a 'security' vlolation). That's easily done when a program is written for a completely different version of FS. Regards Pete

Hmm. It seems rather odd that the altitude of the station isn't relevant. Obviously a station on top of a mountain, nearer the aircraft altitude, would at minimum reduce the actual slant distance to the aircraft. In that thread you said What is wrong with the DME1 elevation provided at 088A? FSUIPC obtains this when it gets the DME1 Lat/Lon data -- it all comes together.Are you saying that it isn't working? If so can you tell me, please whether you are using the latest versin (4.08 for FSX, 3.73 for FS9 and before) and what looks wrong -- I notice later in the thread you were seeing values like 50000, which of course isn't possible in 16-bits -- that's a misinterpretation of a negative value. No, but it would see to be a good idea to get the DME1 elevation sorted out first, then see if you still get wrong answers, doesn't it? Regards Pete

A lot of the PMDG aircraft code is tied specifically to FS2004 and before, simply because of the way it is implemented. I believe it is the PMDG options DLL which provides the menu and links up the various parts of the cockpit, and there is absolutely no way that a module written for FS2004 or before will work with FSX. Sorry, but I'm afraid you'll have to wait till PMDG gets FSX versions out. I am using the PMDG 737-700 and 800 models and AIR files in FSX, but I don't actually use the panels in any case. Regards Pete

Looks like you'll need to stop AutoThumbNail too then. I can only think SimConnect is crashing out on one of these two actions it performs before it sees a "Sim Start" event which says it's okay to get data: Last time I said, of this "it did this well after FSUIPC4 was fully loaded in any case.", but this time (presumably because you stopped two of the programs, it is doing it before anything of FSUIPC appears in the Log, so I assume that's where the Security check is occurring. Regards Pete

In FSUIPC 3.734 (now available in the "Other downloads" announcement) I have, for FS2004 only, renamed that parameter to "CorrectVSsign". This will be done automatically, converting any "PatchSimApAlt" parameters. The parameter stays as it was in FS2002, because in that case it does actually work by patching the FS A/P code, and the Options screen matches that in any case. I've also provided an FSX version (4.089) with the same facilities, excepting that this particular option doesn't apply in FSX -- the other three do though. Regards Pete

Yeah, it fooled me too for a little while ;-) . It's historical -- on FS2002 (?) it did indeed patch the A/P inside FS, something which turned out unnecessary on FS2004, but of course, in the name of compatibility, the parameter stayed for existing INI files, but only doing a bit of the original job. Maybe I'll just change the name of the parameter, and convert any old names. Regards Pete

Okay, I had some time to look at this yesterday (Sunday), so I've implemented pretty much exactly what I suggested in FSUIPC 3.733. Unfortunately I haven't had time to test it -- from inspecting the code it looks okay, but I'd be grateful if you would try it and confirm. Download 3.733 from http://fsuipc.simflight.com/beta/FSUIPC3733.zip This includes a little Text file describing what I've done. I look forward to your results, after which, hopefully, I'll be able to put this into the "Other Downloads" announcement above, and look to do similar changes for FSUIPC4. Thanks, Pete

Ah, yes, I see! Regards Pete

The FSUIPC SDK lets you write a program to read things like pitch, roll and yaw velocities and accelerations. How you translate those into suitable movements for pistons and so on is quite complex. You need to work out the algorithms your specific equipment needs, and then write the driver, interfacing to FSUIPC to obtain the information you need. The SDK is available from http://www.schiratti.com/dowson Regards Pete

Okay. I'll look to implement it as I described when I get the chance, maybe in the next increment. Yes, they look possible in the same way. Keep an eye on the Downloads Announcements above. I'll see if I can get the changes in over the next week or so. Regards Pete

HmmmI wouldn't want to change the way it works at present, for fear of messing up existing installations (I always have to think about continuing compatibility). But I could add such an aircraft-specific option, a sort of explicit override for this global setting. There's not really a good palce to put it in the on-line settable options, and creating new dialogues is more work than I'd want to undertake for such an otherwise simple change. So, how about if I add a parameter which you can edit into the appropriate aircraft-specific section of the INI file? If the parameter is there it overrides the "Miscellaneous" global setting. I think it would have to go into the aircraft-specific Joystick Calibrations section. Please be more explicit. Let's have it all sorted in one update. Regards Pete

Enter hex values as x then the value. Do not enter x at the end,. Offsets need the x at the beginning (unless you are using the decimal equivalents, which is unlikely). The parameters can be hex (starting x) or decimal, as suits the value you need to set. Well, that says the transponder mode control is offset x7B91 (don't use the C/C++ format they give, just precede hex numbers by x, as documented for FSUIPC). So Offset Byte Set, with offset = x7B91, parameter = 1 sets standby, parameter 0 sets normal. The ident is similar but offset x7B93 and parameter 1. Regards Pete

Neither I should think, as they don't really have any relationship with each other at allexcept via SimConnect, that part of FSX supporting both. It's the first time anyone has reported this particular problem, so it evidently doesn't affect evey such user, but it does sounds like a typical example of some of the SimConnect problems experienced before. I don't know why these only affect some installations, but SimConnect does seem to sometmies have problems when there are two or more clients. Are you sure FSUIPC isn't stopping working too? Please check the FSUIPC4 log, see what that says, and possibly obtain a SimConnect log -- directions for doing that are in the FSX Help announcement at the top of this Forum. I can look at those and see if I can see what is going wrong. ZIP them and send to petedowson@btconnect.com. Please make sure you are using the latest version of FSUIPC4 first, though. If you are not already using version 4.08, download it and install it, and then get 4.088 from the FSX downloads announcement above. Regards Pete

Ahainteresting! Thank you for letting us know! Regards Pete

Whilst I cannot agree that it makes ActiveSky impossible to fly with (it still improves on the default weather), this is a known bug in FSX which I reasonably expect to be fully addressed in the forthcoming SP1 update. FSUIPC4 is dependent upon facilities being fixed and added in FSX. I have full intentions to deal with all the weather issues as I can, but the state of the weather control system in FSX's initial release precluded anything further being done at that stage. I don't know, yet, how much more I can do with the SP1 updated version, but I will do what I can and continue to press MS for further changes where needed. Regards Pete

Yes, there is a general consensus that it was released far too early. Hence MS's unusual step of actually promising and working on a bug and performance fix update so soon. Oh, I don't think that is right. It is under continuous development simply becasue (a) it sells well, despite all the problems, and (b) there is always something better which can be done as hardware performance and capabilities improve. You only have to view the different versions over the last 20+ years to see that. I really don't think this will specifically be FSX. The calibration and axis system used in FS hasn't changed since FS2000 days, when they switched to direct input. If the "dead zone" is not truly dead (and you can surely check that in Windows Game Controllers) -- in other words it is actually giving changing values -- then FS (including FSX) will respond to those changing values provided the dead zone setting in FS is set minimum and the sensitivity is set maximum. There is a tendency for FS (FS9 and FSX, and probably earlier too) for the sensitivity to be set far too low and the dead zone possibly too high in FS's settings. Always check those. If you are assigning axes in FSUIPC (as opposed to only calibrating FS's assigned controls), then, yes unless you want the axis to do two things -- whatever FS is told to do and whatever you tell FSUIPC to do. The same applied to joystick buttons. FSUIPC cannot stop FS reading the joysticks itself. Only you can do that by de-assigning axes and buttons or disabling the joystick altogether. I can't really say. Yes, you could do it all via FSUIPC and disable joysticks in FS. That does actuially save having to worry about FS suddenly auto-reassigning axes just because it thinks they are new. The joystick enable/disable doesn't get changed automatically. However, you'd really need to have sufficient reasons for wanting to do it all via FSUIPC in the first place. Different real axes for different aircraft is the main application, the only real thing that can be done with FSUIPC which cannot with FS directly (except possibly in FSX, where you can save and reload different configurations -- but I've not checked if those change joystick assignments too. Might be worth a look?). The axis assignments facilities in FSUIPC are a very recent thing. For its first 6 years the Joystick Calibration facilities were well used, and no one really missed being able to actually assign them in FSUIPC. It was really explicitly for the business of supporting, say, a helicopter control set and a prop/jet control set on the same PC, automatically switching according to the loaded aircraft, which was the spur to the facilities being added. In that case I would extend "fatally" to include a hardware input which is either constantly jittery or which has inconsistent areas in its range of movement -- either due to faults (e.g. dirt in the pot or dry joints.bad wiring) or interference. Additionally, as far as all my testing and understanding of FS's axis treatment is concerned, I believe that, if the axis values are genuinely changing, and the Windows calibration is good, and the dead zone and sensitivity parameters are set correctly in FS, that the resulting internal control values for the assigned axes must also be changing. Possibly, but it would be far better to fix the reason for the noise -- switch cleaner or something, maybe? FS's sensitivity of course isn't related to noise, the latter will be dirt or interference or faults. FSUIPC's filtering is very simple and not extensive. There are some really good filtering algoirithms I could apply, but these depend on building a history of inputs and using this to spot inconsistencies and nullify them. The end result, when done linearly, as necessitated in such a program, is less responsiveness in the controls. The better/stronger the filter, the worse the responsiveness. Believe me, I experimented a lot before including the facility as it is, and you wouldn't like the really smooth results at all. I really don't think that there any such decision made. The calibration of axes is done in Windows before FS ever sees the values. The calibration in Windows is designed to assure a specific range. This is then simply mapped onto the range accepted in FS for the specific control type, typically -16k to +16k for a centering control and 0 to +16k for things like the throttle, spoilers, brakes and so on. The modification to the accepted range which you might observe is caused by applying a dead zone and a sensitivity, both adjustable with sliders in FS. For full range you always need the sensitivity sliders set to max (full right) and the dead zone set to zero (full left). I'm actually quite surprised how good the FSX 737-800 is, considering the 737's in all previous versions of FS were pretty dire. However, its overhead functions are very poor and unrealistic, its engine start-up and shut-down procedures are woefully wrong, and, possibly, yes, its response to controls is still not as good as it should be. In FS2004 I don't think you could beat the PMDG 737s, and I have actually installed the PMDG models and CFG files into fSX --- I don't use any FS panels in any case, being a 100% Project Magenta user. Regards Pete

In FS2002 and FS2004 offset 0D0C is actually mapped through to the real lights flags in FS's own data. FSUIPC doesn't interfere with them, but it does read them to populate the old FS98-compatible offsets at 0280, 0281 and 028C. In FSX, FSUIPC4 assembles the light states from a series of 10 separate BOOLEAN on/off indications from SimConnect. Those indications only arrive, individually, as they change. Either way they should always correctly reflect the state of the actual switch in FS -- although this may not be the same as the state of the lights themselves, depending on how sophisticated the aircraft modelling is with regards to electrical subsystems, generators, fuses, battery switches, etc. They can use the "Monitor" facility, monitoring 0D0C as a U16 in hex, to AdvDisplay for real time viewing on screen, and, at the same time to the normal log so you can see it too. Get them to do simple tests, a known sequence of switching so that you can check it. If you log IPC Reads too, you can relate what you read to the states Monitored. No, not at all. But when you do have some information I will be glad to help analyse it. Regards Pete

Great! Thanks for letting me know. Odd about the modem, though. Regards Pete

Okay, thanks. I'll release it now. Pete

Then either (1) there are two controls for the elevator, conflicting with each other (for instance, make sure there's only one assigned in FS, and also make sure that the flight controls are disabled (not checked) in the Flight Controls tab of PFC.DLL, or (2) there is a fault with the elevator axis on the yoke, in which case it needs repairing. Does it flutter in the Game Controllers test or calibrations screens? If not, then something is interfering with it. Minor jitters can sometimes be eliminated by FSUIPC's filter facilities, but not a real flutter, and certainly not if the cause is actually down to two separate inputs competing to control the elevator. No amount of calibration cures flutter -- it's going to be a hardware problem or conflicting inputs. Try you other joystick as elevator, disconnecting the problem one. If that gives no flutter, connect the original one but deassign it. Does the other give fltter now? Then re-enable the one you normally use and disable the otherand so on. By a process of elimination you should be able to determine whether it is faulty hardware or conflicting inputs. Also be aware that not all USB ports are the same. First of all the ones on the PC are in pairs. Check whether the other of the same pair is connected to something which might interfere. Try swapping that out to another USB port. Second, if you are using a USB extension cable, maybe the voltage drop over it is too much for the device. Try a shorter one or a better quality one. If you are using a hub, make sure it is a powered hub. Regards Pete