Jump to content
The simFlight Network Forums


  • Content Count

  • Joined

  • Last visited

Everything posted by airforce2

  1. airforce2

    Fsuipc & PSS airbus

    This makes sense...I confirmed that the PSS A320 A/P is using only elev trim for pitch control. It does not use the FS A/P...it controls the trim directly. It appears that the 330/340 also uses elevator, which would explain why it works when the 320 doesn't. There's a gent persistently experiencing the opposite problem on the PSS forum...his A/P works, but the joystick axes are dead when he disconnects the A/P for a manual approach. He also gets a full-nose down trim runaway during taxi in after disconnecting the A/P. Sounds like there may be a connection. Regards
  2. airforce2

    Fsuipc & PSS airbus

    I'm not sure that's all of it. I fly the PSS Scarebuses with a full PFC yoke/throttle/rudder combo with no problems. I currently use FSUIPC version 3.317. Regards
  3. airforce2

    Fsuipc & PSS airbus

    I experienced this diving behavior several times, although I am not sure what precipitated it. It was soon after the FS2004 update for FS9 came out, as I recall. I fixed the problem by creating a new flight in FS using the default B734, and with the engines running I switched to the PSS Scarebus 320. Voila...no more Ju-88 Stuka noseovers. I suspect the problem was some lingering .flt file settings...so far the only known way of resetting them all is to load a default MS airplane. Regards
  4. airforce2

    Multimonitor using FSUIPS/WideFS over LAN

    If all you're trying to do is run FS9 across several monitors, the best solution may be to buy one of the many fast dual-head video cards on the market, and run two monitors off one PC. And to a lesser degree of performance, it's also possible to run a 3rd and 4th monitor off a second (PCI) video card on the same PC, assuming you only want instruments and not 3D views. I run FS9 on a 3.06GHz P4 with a dual-head 256MB nVidia FX5600 Ultra, giving me two 1280x1024 displays that appear to the PC as a single really-wide 2560x1024 display that does DirectX or OpenGL acceleration across both. I also have a PCI nVidia MX440 card that runs a third monitor at 1024x768 resolution, 2D only, and it works quite well for instrument panel displays. On my secondary PC, I have another dual-head AGP card, a 128MB nVidia GF4 Ti4600 driving two 15" LCD monitors at 1024x768. I use this PC for Project Magenta, Radar Contact, ActiveSky, SquawkBox, and a few other utilities all running over the LAN via WideFS. I find that multiple diplays on multiple PCs is very cumbersome...getting displayed wx to synch across machines, for example is nigh onto impossible. Cheers
  5. airforce2

    Where can I contact Bob Scott ?

    Phillippe; If you had to fix the old wraparound bug, you are using an extremely old (the very first, in fact) version of the VB .Net SDK interface. I highly recommend that you use the latest version. I use VB .Net programs built upon the SDK here regularly for a number of different utilities. Cheers Bob Scott ATP IMEL Gulfstream II-III-IV-V L-300 Washington, DC
  6. airforce2

    CPU-Cycles WideClient

    I'd be taking a hard look at the timing settings in WideClient if I saw 94% CPU ute rate. Cheers Bob
  7. Pete; I'm at home on holiday next two weeks, so I've lots of time to play with it if you send it. Cheers
  8. Pete; I was wondering if, at some point, it would be possible to provide a new option for the various analog axes on the PFC controls. It'd be nice to be able to map a PFC analog channel straight to a FSUIPC offset, so that an external program could read the raw PFC data...process it...and in turn write the post-processing data back to FS via FSUIPC. Right now I'm trying to write a program that takes throttle inputs and translates them into keystroke controls for the PSS Airbus panels. It'd be a very straighforward thing if I could select, rather than Throttle1, FSUIPC Offset &Hxxxx, have my program read that, and then either pass keystrokes to the panel or set the throttle axis value via a FSUIPC write. There are a few other applications for such an interface I can think of off the top of my head... Cheers
  9. Pete; I think it would be useful for all axes, and the ability to disconnect them is critical in some cases to getting things to work. On pre or post-calibration, I assume that the calibration is context specific, based on the particular axis assignment. I could use either, but for a feature like this less may be more...intent is to divert axis data to an accessible place, and then the programmer is responsible for scaling/smoothing/processing and injection into FS. Simple, directly-readable raw data works for me. One possible use of this capability is to program some means of emulating a Direct-X joystick input from a PFC axis. I note that the PMDG Control Wheel Steering mode (very well implemented) appears to rely on ability to read the joystick axes via DX...PFC serial devices aren't seen and therefore don't work. I'm also interested in software detents for prop controls on several turboprop panels etc etc. Lots of useful possibilities here I think. As always...thanks a bunch!
  10. airforce2

    C# problems

    Ali; To check for the buffer wraparound bug, look in procedure FSUIPC_Process at the first case in the while loop. ("Case FS6IPC_READSTATEDATA_ID") Within that case statement there's an If...should be If(Hdr(2) <> 0) Then If it's more complex (can't remember what it used to be), then you have the bugged version. You might try to cut-and-paste the corrected procedure code from the new SDK. Regards
  11. airforce2

    C# problems

    Rickard--You're correct...looks like an error in the translation from VB .net to C#. I'll send Pete a corrected version for the next SDK update. Ali--the buffer wraparound bug was present in only the very first release of the VB .net API. Make sure you're using the one from the current FSUIPC SDK (v19). Cheers
  12. airforce2

    C# problems

    If you are using the C# API from a version of the FSUIPC SDK prior to version 19, there was a bug in the buffer wraparound that would cause reads to fail and return 0 or other low values when the data buffer wraparound occurred. That has been corrected in the latest version. Regards
  13. airforce2

    PFC com port

    If you're using a serial-to-USB adapter, like the Belkin F5U103, it should have a driver for the serial port emulation. How are you connecting the PFC quadrant to the system? Regards Bob
  14. Pete; When I run the Project Magenta autothrottle in conjunction with the PFC throttle quad, I see spurious excursions of the throttles any time the PFC throttles are out of the full idle position. Would it be possible for the PFC driver to detect the PM autothrottle state, and not affect the axis input if PM A/T is on? Cheers
  15. Pete; I found the problem...the PMDG panel is indeed re-connecting the throttle axes on me. I fixed it by patching out the offending calls. Didn't see it the first time through due to a typo when setting up the control trace...was looking, in effect, for the wrong offsets. Duh. Anyway, she's working much smoother now. It's possible that this was happening all along, but not noticed because I had left throttles all the way back from engagement of A/T at takeoff and beyond. Thanks
  16. Pete; I see this so far only with PM running on top of the recently updated PMDG 737 panel. If I put PFC throttles to idle...or disable them completely in the PFC pulldown menu...everything works OK. If the throttles are connected and above idle, the throttles will momentarily and semi-regularly twitch towards the power setting set on the PFC levers. It's probably the PMDG panel's throttle quad gauge doing this. I could probably fix it by patching out the throttle control calls in the PMDG gauge ...but thought a more elegant solution would be to have PFC driver disconnect the throttle axes any time it's aware of active A/T control (especially PM). Cheers
  17. Pete; When I first fired up FS9 with PFC 1.80 running, it defaulted to the jet 2-engine config for the model I was using. I went to the throttle quad tab, selected User Config 1, clicked on "Assign to Aircraft" and exited. No change. No matter what I did, I couldn't get the config to change unless I exited FS9 and restarted after making the change. That's really painful when you've loaded up 6-7 add-ons across three PCs and have to kill 'em all and reload. I remember being able to change on the fly in previous versions. Cheers Bob
  18. Thanks, Pete. You could add an ini file parameter, i.e. PFCVersion=1.81 and if the version number pre-dates current version (or is missing) it makes the changes to these and any other ini file params that may need changing with an updated version. Then all (3?) of us who make the changes ourselves would just have to add the line manually before we run the next version... Cheers Bob
  19. Pete; I'm seeing the same sorts of things here soon after starting with PFC 1.72...I'm flying the 767PIC right now and #1 throttle has grabbed control of both engines despite having none of the sync options selected in either PFC or FSUIPC. I've also had odd anomalies like not being able to start an engine etc. They generally go away if I restart FS...and if I revert to earlier PFC driver I don't see the glitches. Cheers
  20. airforce2

    PFC Installed but not detecting

    I'm pretty sure I read somewhere in the past that On Top uses same hardware protocol as Elite. Assuming you're using a PFC throttle console...if you remove the knurled nuts on each side of the throttle levers, and remove the lever quadrant, you will see a small silver toggle switch mounted on the panel behind where the quad fits to the front of the console. One position is for MSFS, one for Elite (and presumably On Top as well). I drilled another hole in the back of the PFC cabinet and moved the switch there so I don't have to remove the quad to switch (I also use Elite). Cheers
  21. airforce2

    FSUIPC and VB.Net

    Scott; I tried mightily to make variable pinning work prior to going to the local managed buffer scheme. It was extremely frustrating, and I never got it to work right. Cheers
  22. played with it some...it allows you to pipe a stream of data directly into the playback feature of the recorder. I found it choppy, just as playing back a recording is. Cheers
  23. airforce2

    FSUIPC and VB.Net

    The pesky FSUIPC_Get was written to allow VB.Net to place the results of FSUIPC_Read operations into a managed data structure which is compatible with the .net memory management system. The basic approach is to pass the FSUIPC_Read a reference to a table offset token, and the function returns the offset into the local, .net-managed buffer which will contain the result after the FSUIPC_Process call. The FSUIPC_Get function retrieves the value at the specified offset from the local r/w buffer. This was necessary because just passing FSUIPC_Read a pointer to a variable as in previous versions will not work with the .Net heap manager moving things around. The referenced variable may be moved by the heap manager in the interval between when the FSUIPC_Read and the FSUIPC_Process calls are made, leaving one with a nasty dangling pointer problem. In any event, some of the previously posted difficulties came from trying to read the offset token as data...the first param in the FSUIPC_Get call is the integer offset token returned by FSUIPC_Read, the second param is a reference to the var where the actual result will be passed. The overloaded function defs will pass the correct size/type of data based on the type of the second param used in the call, except for passing of arrays where number of bytes to return must be explicitly coded. Clear as mud? Regards
  24. airforce2

    PFC.dll 1.71

    Pete; In 1.71, the yoke buttons mapped directly to FS from the PFC controls panel (in other words, not via FSUIPC button assignments) have ceased working. If I reassign the button to FSUIPC and do it there, everything works. (?) Cheers
  25. It appears this is the normal flip-flop of values when the input is on the border between two values. I'll call PFC...I have a nice HP regulated variable 0-40v pwr supply that'll make a test of that theory relatively easy. I suspect this is not the problem, though...it's normal for an A-D converter output to oscillate between adjacent step output values. True, but in the scheme I described, a loss of resolution would only occur close to the defined detent positions. Another stabilization methodology would be to lock the output if there has not been more than a six-unit change in the input lever position in the last 10 seconds...and resume normal ops as soon as a 6+ unit change is detected...a variation on control acceleration. That'd be really nice...I also use a Thrustmaster Cougar programmable stick for my heli and combat sim flying...the programmable curves are very, very useful. Would a key/button-assignable axis lock be within the realm of the possible? Basically a software interface to allow equivalent of checking/unchecking the "use this axis" checkbox on the PFC throttle quad page. That way I could set it where I want it, then lock it (by disconnecting the axis) until I manually unlock (reconnect) the axis. I've tried all manner of tweaks to the air files (all my multi-engine turboprops have this problem) and I can reduce the effect of the asymmetric thrust wobbling, but with other unwanted side effects. The most problematic aspect of this problem is in virtual cockpit mode in FS2004, where the VC panel will see-saw back and forth when these oscillations occur. Thanks

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.