Pete Dowson

They don't relate at all. It seems you have ordered and received the USB version of the standard game port pedals. The PFC DLL driver I made interfaces only to the PFC controls systems. the rudder pedals for those plug into the back of the throttle quadrant or other PFC control system. Well, I expect they have to. The game port is dying out. And because of the (Microsoft promoted) gradual demise of the serial port, even some of the controllers have USB connections instead of or as well as serial, now. (The PFC MCP is one such). Unlike the converted Game Port devices (like you have with your new pedals), the controllers use USB as a serial port emulated connection. The FTDI driver which is needed in the PC makes the USB device look like it is on a serial port -- when you check the Windows device manager you'd see the additional COMn port resulting. LOL! It has never been "necessary" -- there was a PFC driver before I did that. It's just that I didn't like it and, with the encouragement of hardware from PFC, wrote my own, which was warmly received by PFC. The PFC.DLL only interfaces to the controllers inside sophisticated PFC devices - i.e. those with 'computers' actually inside. It deals with the PFC protocols these devices utilise. The current examples include the Throttle Control System, the Cirrus II (each of those with optional Avionics stack and RIC), the Professional version of the prop console, the Jetliner console, the MCP (with the optional EFIS and Six-pack modules), and the 737NG cockpit. [Apologies to PFC if I've not use all the right names here]. I expect you could have specified that you wanted to plug your pedals into the controller you already have (it has a socket round the back, hasn't it), and then it would be handled by PFC.DLL. As it is you have a generic USB pedal set which may, or may not, be more flexible for use in the future. Good flying in any case! Regards, Pete

It's a lot of work and may be best left till I have a chance to work on that separate joystick axis allocation system I have wanted to do for a long time. However, it isn't too dissimilar to what is already done for Buttons and Keys (they have aircraft specific sections) so it may be worth a look before then. Something very like what you are suggesting is actually implemented for the PFC throttle quadrants in my PFC driver. In that case it was pretty much essential, since you can actually change the levers to suit each aircraft. Anyway, all I can say at present is that such things are on my list. There's just no way I can give a date, or even a firm promise come to that. Regards Pete

LOL! If I'm not careful I get that way with 737NGs and Project Magenta. I'm getting so deeply involved in the subsystems I forget there are other aircraft which are rather different! :wink: Regards, Pete

I don't understand why you'd need two -- after all it is only FSUIPC you are pausing, not your own threads/program, surely? The problem is likely that, since both threads are in the same program, the memory-mapped filename generated in the SDK code you are using will be the same -- it uses a Process ID to make it unique, but both threads are in the same process. If the identifying string is the same in both cases, the memory-mapped file being used to transfer data back and forth is the same in both cases. Each time you use an FSUIPC_Read or FSUIPC_Write call you are altering data in the SAME memory area but incrementing different pointers. If you really do need two separate links to FSUIPC in one process you most certainly will need to delve into the interface code you are adopting from the SDK and add the thread ID or some other differentiating value to the string generated to make the name. Do NOT change any of it up to and including the Process ID or FSUIPC will nto be able to identify you. However, I do think you are making things too complicated. It will be far more efficient to concentrate all your FSUIPC access in one thread, with one link, and channel all your requests and settings through that. Not with FSUIPC, which is completely unaware of threads in processes outside of FS. You are using interface code in the SDK which generates unique strings as memory-mapped filenames and which uses the Process ID to do this. Opening more than one in the same Process uses the same memory-mapped file. You need to use semaphores to coordinate access and maintain common pointers to use that file correctly. Check the source code you are using in the SDK. You will see what I mean. Regards, Pete

Microsoft's term "FLOAT 64" just means "double" in C, or whatever your 64-bit floating point numbers are called in other languages. "FAKE 64" surely isn't VB's name for a standard 64-bit flloating point number? That sounds very very unlikely. I am pretty sure VB supports standard Intel format floating point, otherwise many programs written in VB would be almost impossible. Please check your VB reference book(s). These are standard Intel formats: FLOAT64 = floating point 64 bit ("double" in C/C++) FLOAT32 = floating point 32-bit ("float" in C/C++) I suspect your "FAKE 64" is some sort of 64-bit fixed point integer, similar to "long long" or "_int64" in C/C++. You would use those for the 64-bit values for Latitude, Longitude and Altitude at offsets 0560, 0568 and 0570. BTW, I see this in your code snippet: / (10001750# * 65536# * 65536#) Why would you try to convert a fuel flow in pounds per hour as if it were a Latitude value in FS units? For it is only such latitudes which are converted in this way. Where are you getting this formula from? Please do two things when working out access to an FSUIPC offset: 1. Check the programmer's guide in the SDK. Look up the varaible in the table. For instance, for offset 0918 it most clearly states that it is a "floating point double" as well as "(FLOAT64)". I would have thought that the words "floating point double" at least could be translated into whatever VB calls them. You will also note then that there is absolutely no conversion from FS Latitude units mentioned for the Fuel Flow in PPH. 2. Use FSInterrogate, Please. This is capable of showing EXACTLY what is being read in several different formats, including floating point double. A version currently being developed will also add FLOAT32 and INT64 (your "FAKE 64" I suspect). Regards Pete

Is that different from Visual Basic? There's a section of the SDK which includes VB. Isn't that any use? I cannot help otherwise, I don't use it, but someone else may chip in here. FSLook operates like a gauge, it isn't an example at all. Use FSInterrogate. That is where you need to go to learn how the FSUIPC interface and the FS values behave. Start with the FSUIPC SDK. All the information you need, if you are a programmer, is in there. If you don't yet program then it may not be a good place to start learning I'm afraid. can you help me? UIPC_SDK VB.NET Shell Rev 2 produced 48 errors in conversion. I am lost! Perhaps your VB Express is more related to VB than to VB.NET? Did you check that? I really know nothing about these many new languages, all apparently incompatible with each other, that Microsoft keeps churning out. Why don't they at least attempt to keep some sort of compatibility? Maybe there's some Help from Microsoft for those changing from one version of Basic to the next, somewhere? Sorry, I am no use for this stuff at all. Regards, Pete

That's not true. I've always used it on another computer, via WideFS. It is connected that way here at this very moment. But then I've only ever used iy with Project Magenta or standard FS autopilots, not with either of the 767's. The difference is, of course, the interface direct to the 767 DLL. It doesn't use FSUIPC offsets therefore WideFS cannot help. Regards, Pete

First of all, please update to the current version (3.48 ). I cannot support such old versions as 3.411. Then if you get the same, or any other problem, ZIP up the log together with your FSUIPC.KEY file and sent it to me at petedowson@btconnect.com. I will check it here. The only reason so far there's ever been any problems with registered installations but not unregistered is that the access key is incorrect in some way. I'd need to check. Provided you obtained it legitimately it should be fine. Regards, Pete

Ahthere's something wrong with the Level D installation then, by the sound of it. If the computer is slowing and freezing then WideServer is too. WideServer cannot run if FS cannot run. They are limited to 22, but what are you getting with the level D? You just said the PC is slowing down and freezing. Surely it isn't maintaining 22 fps during those times? You aren't trying to say that WideServer is freezing the PC are you? Test without first. 1.8 seems very slow for processor speed with a complex aircraft such as the Level D. I assume you must have many features in FS2004 turned way down? Even my 3.4 GHz PC would struggle. Well, it's not quite the same as a Network printer, but it might be that the driver is doing something all the time across the link to the PC with the printer on it, so it would be a good idea to eliminate that possibility first. However, that would affect everything, not just the Level D aircraft -- there's no way the printer driver would know or care what aircraft you are loading. No, I've never heard of it being a problem. But we have no idea what you've changed to cause this except that you said the only thing you've changed was to install a printer. Therefore, logically, that's the first thing to check. However, uninstalling and re-installing the Level D aircraft seems like the logical next step after that to try, from what you've now said. Maybe something in that has got corrupted. Regards, Pete

No, the Server is seeing messages from the Client, it is the Client not seeing anything from the Server. That's why it says "Timed out response". The cause of the problem could actually be at either end. With only one client it is difficult to isolate -- with two it is easy because either both clients suffer or only one. The trouble is there are no errors being reported. It simply looks like the data is transferring okay Client to server, but not Server to Client. Something is stopping it. How do you mean? If you change aircraft it all springs to life? What sort of "general crash"? And we don't know that it's a Client problem. If there's only a problem when using the LDS 767, maybe it is taking too much of the FS processor and not letting WideServer run -- though I've never heard of such a thing before. What processor is it? What is your FS frame rate limiter set to? What are your frame rates? You said this started after you installed some driver -- for a printer? Try uninstalling or re-installing that. Was it a Network pronter by any cance? Regards, Pete

Well, apart from the documented conversion you need to apply to get them into degrees, yes, I think so. I don't know exactly what you really mean by "Earth - fixed - inertial reference frame", but I suspect you mean the attitude in FS's small and oddly-shaped universe (its Earth isn't a sphere nor a plane, remember, more a toroid if I remember rightly, with no poles). Anyway, in FS, the exact position and attitude of the aircraft at any time is given by the 6 values LLAPBH (Lat, Long, alt, Pitch, Bank, Heading) in the offsets 0560-0580. Please try using FSInterrogate, provided with the FSUIPC SDK. You can see these things actually changing in real time and therefore come to understand them quite quickly and thoroughly. Regards, Pete

This phenomenon is actually described in the documentation, and has been for years -- please see the section entitled "Running WideFS". I think the explanation starts in about paragraph 5. That's the Server log, which doesn't show a problem. It's the Client which is re-connecting, probably because it is timing out messages from the Server. Something is probably stopping them in the Server, but you need to look at the Client log to see what it says, first. Regards, Pete

Well, it's just the one I've been studying most and attempting to simulate thoroughly in my cockpit. A 737-700 to be specific. ;-) Sounds okay, but you'd have to logically 'or' the multiple conditions. And of course the indication wouldn't necessarily tell you everything was okay because if one Hyd system is down some things wouldn't work. Well in the default FS aircraft it does because it doesn't simulate the subsystem very much -- the cockpits don't have the switches. In my cockpit I have the four switches -- Electric and Engine pumps for system A and system B. Certainly you get no pressure if no pumps are on. But there are no pumps or switches in FS itself, only in add-ons. There's a reservoir for each system, including the standby, so you do still get some hydraulic pressure for a while after the engines are switched off, but I assume it will decrease quite rapidly if you actually try using anything. You have to take care not to switch on System A pumps even with engines off before pushback, because the nose wheel steering could become activated with remaining pressure, and that could be dangerous for both equipment and groundcrew -- pushback needs a "loose" nosewheel. Same goes for flaps and things moving when there are groundcrew around. Regards, Pete

They mean pretty much what they say as far as I know -- the angle to be indicated on the FD and AI insttruments. No, only to show what the stated aircraft instruments show! If you want to indicate the attitude to fly manually to follow the VNAV/LNAV path set for the AutoPilot, use the FD values -- that's what the Flight Director is for, to help the pilot fly the plane. If you want to make an Attitude Indicator use the Attitude Indicator values. If you want the current true attitude use the true attitude variables available elsewhere -- there can easily be a difference between the actual current attitude and the attitude indicated on the AI. It's to do with momentum and other effects, as well as power and vaccum systems availability. Pete

Answered in your private duplicate. Pete

Please see the PFC DLL documentation! In the section entitled Button Assignments (in PFC options) you'll find it listed in the table as "PTT Roger Wilco (local)". For SB3 running on a WideFS client use the one below that instead, and edit the WideClient INI file to suit, as described in the WideFS documentation. What does "unlocked" mean in this context? If you cannot achieve full reverse then you have not calibrated correctly. Always leave a little bit of slack at BOTH ends of the lever movement when clicking the buttons in FSUIPC to tell it where the minimum and maximum points are -- all these devices are subject to variation (heat, humidity, physical variations), and if you don't "waste" a little of the movement at the extremes the minimum and maximum values you achieve will vary every time. Regards, Pete

In an airliner I am pretty sure there are always at least two hydraulic systems, powered by separate engine-driven pumps and/or electric pumps, with the latter powered by different electric subsystems / generators. For example, in the 737's Hyd. Engine 2 pump and Hyd Elec 1 pump power Hyd. system B, and Hyd. Engine 1 pump and Hyd Elec 2 pump power Hyd. system A. This cross-over system allows two separate original sources for each system, as a failsafe. In normal configuration the hydraulic needs in the 737NG series are shared as follows: Alt Brakes, Left Flight Spoilers, Ground spoilers, Landing gear, Nose wheel steering, A/P A -- System A Nml Brakes, Autoslats, Autobrake, Right flight spoilers, Flaps, Yaw damper, A/P B -- System B Rudder, Ailerons, Elevator and "elevator feel" -- Both A and B. There is also a standby hydraulic reservoir and associated system which I won't go into here. For 737 stuff see http://www.b737.org.uk/index.htm. It doesn't really do a lot of the sub-system simulation -- I use pmSystems and program it there. But all this is, of course, very aircraft specific. I expect some of the more sophisticated models like the PMDG 737NG and the LDS 767 simulate this stuff very well. But I think you are mistaken about the hydraulics -- where there are multiple systems you get multiple pressure readings. In the case where two or more systems are feeding the same actuators I expect you can add the pressures, but why would you want to? Regards, Pete

Yes. In any case 3.41 was already changed to work with both FS9 and FS9.1. The current version of FSUIPC is compatible with FS98, FS2000, CFS1, FS2002, CFS2 and FS2004 (with or without the update). Once having achieved compatibility I try very hard to maintain it as I don't want to have to support more than one version. In any case, there's no risk on your part. You just replace the DLL in the FS Modules folder. That's all an "upgrade" is. You can easily keep old copies if you want to and revert just as easily (but just don't ask for support for them). :wink: In other words, it isn't a big deal. Just one little file being changed. Regards, Pete

Sorry, I don't understand. Add the IP address to where, what? Each WideClient only deals with one Server. It can't answer to two masters. Who would it believe for downloaded data? How would it know who to ask for what? Yes. If you set that non-zero then Wideclient will run on a PC with FS or other WideClients already running. It can then be configured to talk to a different server. The problem then is that the application program won't interface to it unless it is changed to find the different Class name -- and that's in the library folks usually use, so it means them getting inside the source (which is provided too, however). It wouldn't be a completely trivial task for them to undertake, and they would (probably quite rightly) ask why WidevieW isn't handling it better. After all, as I said before, it is really its job. "Runs the weather through ..."? I don't think that is relevant -- it isn't the data that FS needs. That goes through FSUIPC, not ActiveRadar. Of course not. Cloud textures have always been held in the textures folder in FS. It is only ASV which recently started doing that. I don't think there's anything else that'll handle textures -- I thought it was the actual weather you were concerned with. If it is only the textures, turn the texture part of ASV off. Regards Pete

Please upgrade to version 3.48. Version 3.40 is now very old (nearly a year) and there have been many fixes, changes and improvements since then. I cannot support old versions. Go get the FSUIPC SDK from http://www.schiratti.com/dowson and check the Programming document. That contains a large table of offsets which most certainly includes such information, but possibly not by those names. Regards, Pete

I'm afraid you'll need to change the conditions used in each case then. Let the values run from 0 to 2 and 0 to 3 (instead of 6), and change the conditions 12 to 18 accordingly. Delete the lines for the unused radios in each of the two device sections. Regards, Pete

No, sorry. The base is always zero. The parameter is just divided into two parts -- the increment and the upper limit. The lower limit is always 0. What sort of application needs 3, 4, 5, 6 and not 0, 1, 2 as well? Possibly you could use a cycle from 0 to 3 and just add 3 in whatever is using it? Regards, Pete

There is an elevator trim axis calibration facility in FSUIPC, if that's what you want. For the operation of this with A/P see the "Disconnect elevator trim axis for A/P" option in the Technical page. These things are described in the User Guide. BTW the current supported version is 3.48, not 3.47. Please upgrade. Regards, Pete

This is where I failed to make the association. Hmmmyou've lost me now! Where's what associated with what? Regards, Pete

Sorry, it was in no means a "technical" or "programming" term, but two ordinary English words juxtaposed in what I had (wrongly?) assumed would still make sense to you = "state of the shift" == "shift state". You wanted two states, shifted and unshifted, right? You yourself started using the term "shift" for a key you wanted to use to get two functions on one button. The "state" of that shift button is then obviously a "shift state" -- i.e shifted or not shifted, shift on or off, whatever. The word "state" is normal English. The word "shift" I thought you already understood because you started using it. :) :roll: :) Occam's razor? Yes, why not always take the easiest course? I myself should try doing that more often. It would sure save me a lot of development work. :wink: Good luck, Pete