Pete Dowson

Yes, sorry. The whole of this area of FSUIPC has been revised and works correctly now -- please check the Interim Versions announcement near the top of the Forum. That's a question for the iFly folks. I'm afraid I don't know what they are doing which makes the axis use unacceptable. It would certainly render their aircraft unusable on my cockpit. Regards, Pete

What is the version number of the "older version of FSUIPC" please? FSUIPC has been around now since 1999. It is impossible to help without more information. What program is providing your "ACARS"? Is it one with access accreditation to FSUIPC, do you know? Tell me the program or gauge name and I can check. Possibly you should ask the author too. I assume you've not registered FSUIPC yourself? Finally, there will be a file generated in the FS Modules folder called "FSUIPC.LOG". Let me see that after an unsuccessful attempt. It sounds like the program you are trying to use is not licensed for FSUIPC, but give me some details I can work with and perhaps I can reply more definitively. Regards, Pete

Yes. Unless you want to do clever things with the main X, Y, Z axes, you might as well assign them in FS. You can still calibrate them more precisely in FSUIPC, and assign response curves to get the sensitivity you like. That's the advantage of FSUIPC calibration. The axis assignment facility is a bonus mainly aimed at more ambitious arrangements. I think for you, this is the easiest: forget the Axes tab in FSUIPC. If you have already assigned Axes in the FSUIPC axes section, yes, go there and clear them, otherwise you will have a double action. Then just get everything assigned and working in FS alone. Then, as you like, calibrate the X Y Z in FSUIPC -- that's in the Joystick Calibrations section. Regards, Pete

Ahapologies. The controls are actually named "Trim up" and "Trim down". Looks like the "Elev" bit is dropped. FSUIPC gets the list from FS, it isn't its own, and I think these are converted from the "Num1" and "Num7" control names which are rather meaningless. Yes, but why use FSUIPC to assign controls to buttons which FS supports well enough itself, and normally assigns automatically in any case? In other words, why are you confusing yourself with FSUIPC doing just standard things which FS does reasonably well by itself? There must be more to what you want, surely, than simply assigning X Y Z and trim? FSDUIPC's facilities are really provided to augment what can be done in FS, not simply do the same. Regards, Pete

What were you using to assign the axes (FS or FSUIPC) and what version of FSUIPC? Have you seen the interim updates available above? Yes, this is called elevator trim. If you want to assign the buttons in FSUIPC, go to the buttons page, check the option to use controls, find in the drop down the "elev trim up" and "elev trim dn" controls, assigning them each to the correct button press, and remembering to check the "repeat" option. As I explained before. Using buttons for trim up and down is also the default way FS assigns these, so I really don't understand what you are doing in FSUIPC in the first place. Sorry. Regards, Pete

Well, I originally thought it was a good idea, but it seems that FS puts them back in any case, eventually. So I wouldn't worry about them. If you are doing ALL your button ands axis assignments in FSUIPC, just disable the joystick in FS's Options-Settings menu. (There is a bt of a discussion about this in the FSUIPC documentation). Regards, Pete

There's no such commands. You can assign the Elevator to an Axis elevator set command -- not a separate pitch up or down. It's a normal axis with a centre. There's an Axis set command also for elevator trim. Again, it has a centre, but certainly not a separate up and down. I really don't understand what it is you are trying to do nor how you are trying to do it! What elevator trim up/down setting are you talking about? Please try to separate BUTTONS and AXES. They are entirely different things! What has any of that got to do with the trim? Surely you use X for aileron, Y for elevator and Z for throttle (usually)? You said earlier that you'd disabled it all in FS, so this could be why it doesn't work, no? Why not start again? Remove FSUIPC, delete FSUIPC.INI, run FS and sort out your joystick assignments there. I think until you can say what it is you want to do you will be better staying with the simple things. Regards, Pete

FSUIPC never works in any new version of FS until I've made it so. In fact it doesn't work in any updates to any version of FS until I've made it so, as illustrated by the FS9.1 upgrade. Even if I could I wouldn't be allowed to yet. Sorry. Yes. If I do my job well, why should there be any? Do you know more than me about FS10? (It would certainly not be hard to know more at this stage! ). Regards, Pete

Er, sorry but I am a bit confused by what you say. Are you talking about elevator TRIM? You want a trim up button and a trim down button, right? If so, this is nothing to do with FSUIPC joystick calibration -- you don't calibrate button presses, they are simply buttons. You program the trim up and trim down controls in the Buttons and Switches section. Try that. In the drop-down control lists they are "Elev trim up" and "Elev trim dn". Also check the "repeat" option so they repeat whilst held down. Regards, Pete

Yes, and oddly enough it is described in the WideFS documentation under the heading "PTT (push to talk) for Roger Wilco, AVC and TeamSpeak". Pete

Yes, it is part of the TCP/IP package, and is used by windows in any case I think. Sorry, I've no idea on that one -- I was a staunch Win98SE user, refusing to update any of my PCs until I had to on one of them because Matrox wouldn't do a Win98 driver for the Parhelia. I still resisted with the other PCs after, until the SP1 update arrived -- that made a helluva lot of difference, and I changed my mind! Whether Win2K would have changed my mind I've no idea. I have one machine, running WinXP Pro normally, which has Win2K Pro on dual boot, but apart from testing things in it I haven't formed any opinion. Sorry. Regards, Pete

Sorry, I do not know what the "client manager" nor "IBNet" are at all! Are you sure you are asking this question in the right Forum? You mention FSUIPC, but what has that got to do with it? Pete

Sometimes they will, sometimes they won't -- you can't tell. Windows has loads of other things to do. The Process call (not the others) is not only relinquishing control to FS, but also to anything else that wants to run. You cannot guarantee your 256 Hz in any case unless you have a tight loop in a thread which is set to high priority and shares only with a Sleep(4), say, to regulate it to 250 Hz. You would have to get the FS values in a separate thread, or the main program, probably on a timer tick call (SetTimer) every 55 mSecs (the normal tick resolution), and have your fast driver loop just picking up the last value from wherever the FSUIPC access part dumps it. It may be better to do some interpolation as well, if you can. I haven't done any, but I should think it is all based on the accelerations, not on the pitch/bank and heading values. Then you have to slowly bring the base back to centre before you run out of tilt capability. Only accelerations are felt -- you can add the thump of the gear coming down and the landing too of course. And a continuous gentle vibration (probably easier done with a bass woofer). Regards, Pete

256 Hz? That's allowing less than 4 milliseconds for each double process switch (switching to FS to ask for the data and back to you to process it). I don't think Windows is capable of that on any PC yet, at least not consistently and allowing for any work to be done by either party. It is in the process switching where most of the time is spent. The rest is then mostly taken up with message queuing in Windows. All this is outside FSUIPC's control, which does things as fast as it possibly can once it gets the request. In any case, for most values you will want, FS is only updating them at a frame rate -- not necessarily the visual frame rate, but not much different from it. If I were you I'd regulate FS to a frame rate you can always sustain (say 25 fps) then interpolate for the other 9 values you need per frame. Regards, Pete

For VB.net? I thought he was a Delphi programmer. I'll ask him next time he's around -- I think he has very busy periods work-wise. Thanks! You're a star! ;-) Pete

Hi again Nobbi, I just noticed this: ... so, as I obviously have this aircraft I thought I'd take a quick look. With the default Baron, if I set the thottles to give a steady reading of 1500 RPM on the FS panel, I get the following through FSLook and FSUIPC: FSUIPC: 0898 = 9128 (decimal) 08C8 = 10800 So RPM = (9128 x 10800) / 65536 = 1504. Correct! FSLook gives 9130 or so -- i.e. the same value as 0898. So, I'm afraid I cannot agree with you regarding the Baron. How are you arriving at your conclusions? Regards, Pete

That's very very strange. Is there any relationship? Maybe the scaling value is wrong for some reason. Can you quote some comparative figures for me? I seem to recall that it somehow reads the Gauge values. Not sure how, I'd need to burrow into the code. Are you writing something to run inside FS, or is this an external program? If inside FS you could try reading the Gauge token variables. I *thought* that they came from the same place as those 2400 etc offsets, which is why I'm puzzled. Well, not really sure, but maybe it works on one version of FS and not another -- it is possibly making some assumptions somewhere which turned out to be incompatible. Let me see a two columns of comparative figures, please, see if there's a relationship I can figure. Regards, Pete

That sounds like it uses TCP/IP routing, then, even on the same PC. Similar maybe to remote DDE. Yes, but such data exchanges would be far less efficient than direct exchange using shared memory, which is what FSUIPC's IPC uses -- the same technique as used in Debuggers for dealing with process memory. There is really nothing more efficient than sharing memory for transferring data in one PC. And having all of FSUIPC's offsets universally accessible across the network without specific data requests would represent a huge amount of traffic compared to the efficiency with which WideFS is able to run, supplying as it does only changed data for those programs specifically requesting it. To judge how it would be, try putting FSInterrogate on a Client, select ALL offsets and have it regularly reading them. And that's with WideServer sending only changes -- imagine if everything was sent all the time. Believe me, a lot of thought went into the design of my programs. I wasn't thinking of pointer arithmetic, but simply the apparent problem in passing data by reference (i.e. pointers), as is needed in the FSUIPC interface. I had been led to believe that all this "token" business and the need for an extra "Get ..." after the FSUIPC Process was needed because of this inability. Otherwise, why aren't the values being read directly into the variables as in non-managed languages? Ah, in that case, would you like to volunteer a more efficient, more friendly, solution for the SDK, pretty please? ;-) Regards Pete

Odd that the values are different. Possibly it comes from a mismatch of aircraft to FS version. Have you checked the RPM values available at offsets 2400, 2500, 2600, 2700? Regards, Pete

So what stops them containing calls to the main Windows API DLLs? What stops them doing standard memory allocations and using memory pointers, the lack of which appears to be the reason behind the "token" stuff in the .NET FSUIPC implementations? Everything I've read points to a lot of "protection" imposed on these prograns by the 'framework' layer that smells exactly like interpretation to me. Evidently I've not understood what I've read about them, but I also don't understand how they can be so restrictively "managed" with something very like what I call interpretation. Regards, Pete

Sometimes folks get this sort of behaviour over in the PM support web/newsgroup. Did you check there? I'm not sure what the causes can be -- maybe something has a memory leak (do you notice an increase in disk activity?), or the network drivers for your network card, or maybe your hub or switch, is having problems. Or the video card/processor is simply not up to the job at the frame rate you are trying to drive it all at. Are there any errors being reported at all in the WideServer or WideClient logs? That's really always the first place to look. The other thing to check is the video drivers, especialy if it is only occurring on clients which are heavily display based -- the PM PFD.EXE program being a prime example. If it isn't happening with the CDU or MCP software, for instance, then this would tend to indicate something to do with the display system. If there are no errors reported in the Logs, then the delays, if any, will be occurring in the lower levels of Windows network drivers -- maybe running out of buffers on a system where the processor is overloaded and not allowing the main application (PFD) to keep up with the traffic. WideClient won't be queuing anything -- if an update comes in before the previous one is requested, the previous one will simply be overwritten, so it never knowingly supplies anything out of date. What I think can happen, though, is that the PFD software and the video drivers it is using are taking so much time out of the processor that Wideclient isn't actually able to read the incoming frames fast enough. There are two things to investigate, apart from checking the logscompare the FS frame rate with the frame rate achieved on the PFD software. Try limiting the FS frame rate to something which can be matched by the client PC. And see if the video card and driver is causing any problems, hold ups -- ask in the PM group about this sort of thing. There are some known problem cards I believe. Another thing you could improve is to replace the 5-port hub by a switch. Switches used to be more expensive, but they are as cheap as hubs these days and much more efficient. BTW have you tried the latest interim version of WideFS? We're up to version 6.615 now. The UDP protocol, now supported, can be significantly faster than either SPX or TCP, but it is less reliable. you have to try it and see -- check the logs afterwards. Regards Pete

I hope someone who knows VB.Net will chime in and help, as i don't know it at all and some things about it seem positively weird. I guess most of the weirdness (for me) stems from it being a "managed" (interpreted) language rather than a true fully compiled one. Well, apart from "token" which is a puzzle to me and only seems to appear in the managed language versions, the others were certainly explained in my original notes for C programmers. I'm sorry if none of it came through in those voluntary contributions. Anyway: dwOffset is the offset as listed (in hexadecimal) in the main document with the long tables of variables. I think in VB you need to be careful of those greater than 7FFF since VB seems to assume 8000 and more are negative, and fills the rest with ones, making FFFF8000 etc. To stop that I think you have to postpend another $. dwSize is simply the size of data (the number of bytes) you want to read or write. The FSUIPC interface can read or write as much as you like, up to the buffer size limitations, but usually, if you are reading into a single variable rather than an array or structure you would set this to the byte size of the variable you are using, such as 4 for a 32-bit integer. The only other parameters defined in the FSUIPC interface are a pointer to where to place the result (your variable) -- or, for a write, where to get the value to write -- and a place to put an error number (result) should anything go wrong. You don't need to look at the result unless the function returns FALSE, to indicate a failure. Not sure that Forums can have sub-forums like that, but there have been plenty of threads with examples, at least in VB. Some in VB.NET too, I'm sure. Sorry, but scanning or searching may be the only way to find them. Limiting your search to this Forum with VB.Net as a keyword should turn up something. The latter two sound okay, but I'm not sure what is going wrong, if anything, with the data. I'm afraid someone who knows VB.Net would have to help there, unless your compilation system comes with a debugger, in which case you should be able to trace it through. After all, all the source code is provided and is part of your program. FSUIPC (the bit I know) only gets involved in one SendMessageTimeout call within the Process routine. Are you using FSInterrogate as your reference rather than the documentation, where it does tell you the units? FS stores many angular values in 16 or 32 bit integers, making maximum use of the capacity of those bits. So, since the range of angles is only 360 degrees, the most accuracy is achieved by making the whole range of values possible in 32 bits represent those 360 degrees. Thus 360 degrees would be represented by the maximum number possible, plus 1. The maximum number in 16 bits is 65536, the maximum in 32 bits is 65536*65536. Thus you can see how the formula is derived for converting the value you read into a proper angle in degrees. For accuracy and ease, you should copy the value you read into a floating point variable (I assume VB.net WILL do the conversion as other languages do?), and only then multiply by 360 and divide by 65536*65536 (or just by 4294967296, which is the same thing but harder to remember ;-) ). Regards Pete

Well, it's possible, but I wouldn't like to say that without looking at the logs first. It may be something easier. Regards, Pete

If it wasn't you'd probably get an error message. But you can check in the FSUIPC Log to see if it says it registered okay -- things like that are logged there. Regards, Pete

Okay. Good. The current Interim Version is 3.615, available above, so you may like to upgrade once again! ;-) Regards, Pete