Jump to content
The simFlight Network Forums


  • Content Count

  • Joined

  • Last visited

Everything posted by airforce2

  1. 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
  2. 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
  3. 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
  4. Pete; I too see an incessant wobbling about on my turboprops caused by unstable PFC inputs going to the prop RPM setting. I'd like to put on request a powerful new feature in either/both of PFC/FSUIPC, in the form of a programmable "soft stop." It would be exceedingly useful to define, say 1-3 points in each axis range that represent a physical detent. When a preset value is reached, the output would "stick" and remain at that value until the lever is moved beyond a predefined threshold. For example, in the Dash-8, I need the ability to set prop RPM to full (1200 RPM), 1050 RPM (climb), and 900 RPM (cruise). Full-scale needs no stop...but when I set 1050 RPM, pot noise causes the prop RPM input to bobble about +/- 3 units, which is enough to swing the nose about noticeably. I would like to define an input value and a threshold...in effect I would set it so that when the prop input reaches x units, it "sticks" at the corresponding output value until I move the lever at least y units (the threshold) away from the detent. Even better, forcing an audible "click" (play a wav file, perhaps?) when reaching the detent would be ideal. Additionally, sending a keypress upon reaching a detent would be useful for some panels (like the PSS Scarebus 320/330/340 panels) which use keys to advance/retard the throttle to the Rev/Idle/CLB/FLX/TOGA stops. This would also be useful on the throttle axis at an idle detent...at the click, the throttles remain at idle...to go into reverse or forward, requires movement beyond the detent threshold (maybe 6 units or so?). Alternatively, a function to manually freeze prop inputs until input lever is moved beyond a threshold would also be helpful...I'd like the ability to press a key or yoke button to lock the props and stop the constant hunting. Cheerio
  5. airforce2

    Correct 100K Pot readings

    RVDT = rotary variable differential transducer
  6. airforce2

    Question for Mr. Dowson

    "WarpD" You'd find thousands of members in any Pete Dowson fan club, a group which I would be proud to call myself a member. Clearly, you have no clue how much he's given to the hobby for many years now. Ask around. Once again, you embarass yourself. It surely is my choice to point that out, whether you like it or not. The MSFS analogy is a clear parallel. My 13-year-old son had no problem understanding it. Sorry you're not able to grasp it. It speaks volumes about Pete that he's still offering to help you obtain free accreditation even after your hostile initial volley (all while hiding behind a pseudonym).
  7. Pete; OK...fair enough. I think I'm going to try writing a CAS alert program that will overlay a black text box over PM's EICAS to display CAS messages. I can code the ice detection in there. Cheers
  8. Pete; Using ActiveSky wxRE 1.91 beta 6, I am seeing a recurring problem where the indicated airspeed reported by FSUIPC via WideFS drops to zero for 20-30 sec as I approach a cloud layer in the descent. The latest episode occurred descending through ~14000 ft MSL close to the top of a scattered cloud layer with bases at perhaps 12000 ft. It appears that only airspeed is affected...other params appear normal. This behavior began with installation of both FSUIPC 3.06 and the Beta 6 of wxRE. I also reported this on the ActiveSky forum, as has at least one other person. Regards
  9. Pete; Well, suppose it's possible that ActiveSky is doing it...I need to re-engage with them on that. I did see ice values of 4 several times watching it with WeatherSet2 over the course of 15-20 min. The issue is realism...one doesn't normally fly with anti-ice on unless either you expect to climb/descend through forecast icing, or in-cloud with temp < 10 deg C (or as specified by acft ops manul). Problem is, you can be in the cloud layer some time before actually visually entering the clouds themselves. I sent a note to you and Enrico re: possibility of adding an FSUIPC offset for current icing condx, and adding an amber "ICE DET" EICAS message in PM to announce icing is present. With an icing indication, we can reach up and turn on engine A/I and solve the problem. Cheers
  10. Pete; I tried same experiment...saw the same. In severe icing, I'd expect massive accumulation on the wings, even with anti-ice on...but I can't conceive of severe icing that'd accumulate on the probes themselves when they're heated. Those things will burn the fingerprints right off your fingers if you make the mistake of leaving 'em on while on the ground. Been there, done that. I actually got one of these dropouts in a clear spot between the clouds...don't think FS differentiates between clouds and clear spots...it just looks at layers. Is the "random" icing level in clouds written by FSUIPC or an FS feature FSUIPC activates? If an FSUIPC feature, would it be possible to limit random icing in clouds to level 3 or below? Cheers
  11. airforce2


    As far as I know, the PFC USB controls all use standard MS HID miniport drivers. They are treated as a Windows standard joystick...i.e. buttons are programmable as Direct-X buttons within FS2002 itself. Regards
  12. airforce2

    Correct 100K Pot readings

    Another good option is to use Hall Effect RVDTs...they provide very good resolution and are generally much cheaper than optical encoders. Cheers
  13. Pete; On my clients, I use a KVM switch to share the keyboard, video, and mouse. The KVM switch uses a key sequence SCROLL_LOCK, SCROLL_LOCK, up/dn arrow to swap between the two. With WideClient 6.1 on the clients, if I press the scroll lock key sequence, it puts the server into pause mode. Any idea how I can stop that? Cheers
  14. airforce2

    Question for Mr. Dowson

    Geez...not another one...what is this, the "Trollz-R-Us" forum? Hey WarpD, is it fair that Microsoft profits by selling Flight Sim to every one who wants to use one of your panels? Is it fair that Microsoft gets to profit from selling the operating system that flight sim requires to run? Sure it's fair...if you don't want to pay them to reap the benefits of their work, then go find something else more to your liking and price range. Pete's more than fair...he accredits...FOR FREE...legitimate freeware works that use his interface software. He sure doesn't have to, and with all the crap he takes from people that can't bother to read his policy before spewing forth with accusations and complaints, he'd be more than justified to just ask everyone that uses FSUIPC to pay for it. It's certainly his right...none of us have any claim to the fruits of his labor for free. What's particularly annoying to me and I presume many others, is that you can't afford Pete the decency to have this discussion with him via private e-mail, rather than tossing this sort of accusatory rubbish out into a public forum. It might have saved you some much-deserved embarassment.
  15. Pete; I don't doubt that guys land 'em crabbed. It may be that the pax get uncomfortable coming down final in a bank...it does feel a wee bit unnatural, especially if you don't know what's going on. In my years of GucciJet aviatin' (in Gulfstreams) I generally employ the technique of flying final approach in a crab until about 1-2 mile from the threshold, then establish a wing-low slip in plenty of time to be stable for the landing. Then there's the whole discussion of the "reverse weathervaning" or "buggywhip"...when you touch down in a crab the pointy-end will swing rapidly to point along the ground track. I used to be an instructor in the T-38 Talon, which is one jet you do land in a crab intentionally (but it's light). That buggywhip effect would spin yer eyeballs pretty good when you planted one in a stiff x-breeze. Cheers
  16. Pete; The icing level reported by WeatherSet2 during another zero-airspeed incident was 4...I think the problem may be that even pitot heat is not effective in extreme icing (as would be the case in reality). But...to see that level of unforecast icing routinely isn't realistic...perhaps the probability programmed into the randomizer is set too high. Also, significant structural icing at temps below ~-20 deg C is very rare, as ice tends to sublimate off the wings. Hence icing at 35000 or 52000 ft (as I've observed a few times in the last couple hours) isn't very realistic...not sure if that's the AWI or ActiveSky doing that. Anyway, I'm turning random icing in clouds off in FSUIPC...if I see another zero-airspeed hit with it off I'll readdress here. Cheers
  17. Pete; Not completely true...real aircraft do indeed weathervane in the air. The airplane rotates about the CG...and the side load imposed by a crosswind striking the vertical tail at considerable arm (distance) from the CG will produce a very real leeward yawing moment...aka weathervane. This is most noticeable on takeoff with a strong x-wind...as soon as you break ground (where you've been steering straight down the rwy with the aid of nosewheel steering) the airplane will yaw to put the pointy-end right into the relative wind. The cause is the fact that the airplane was not flying directly into the relative wind while on the ground, and at liftoff, it still has a considerable inertial vector in the direction of its ground track at liftoff (straight down the runway), leaving the aircraft in flight at an angle offset laterally to the relative wind. If one adds rudder to counteract the yaw, the ground track will shift downwind and progressively less rudder will be needed until, after a few seconds, the airplane is at equilibrium into the r.w. I'd be surprised if crabbed landings in any transport category aircraft are enything but poor pilot technique. As I understand certification standards (FAA and/or CAA), the aircraft should be capable of holding a wing-low slip with the fuselage pointed straight down the rwy...with an adequate bank angle safety margin...at the max certified x-wind. The side loads imposed on the side braces and support trunions in a crabbed landing are pretty severe. Regards
  18. Pete; I wish it were that simple...probe/pitot heat's on and verified (in both the panel and using FSLook to make sure the sim thinks so) in all three occurrences. PM also reports Pitot Heat on at the time it happens. The A/S drops abruptly to 0...then without any other action on my part, it returns 20-30 sec later. In the meantime, the Project Magenta MCP has poured the coals to it, sensing that we're seriously slow (can't get much slower!), so when A/S indication returns, I'm at Vmo+20 or so. Cheers
  19. Pete; Tried it without APS.DLL in the modules folder...no change. Have been doing research this morning on interrupt affinity masking...there's a utility in the Win XP Server 2003 Resource Toolkit that allows you to set processor affinity for drivers doing hardware interrupt handling, which may be at the root of this problem with serial I/O. The utility is called intfiltr.exe...you can download the WIndows XP Server 2003 resource toolkit from support.microsoft.com. The utility applies to Win XP pro as well as Win XP Server 2003 per the docs. With the serial I/O interrupt handling set to CPU0, the PFC driver still drives both CPUs up to 100% when FS9 is set to dual-processor affinity. I've also discovered that the sound card (Audigy) does not take well to having its interrupts tweaked...it hisses and pops like mad when you do. Lots of other interesting possibilities are unfolding. Cheers
  20. Pete; I just tried with the PFC controls connected via a Belkin F5U103 serial-to USB adapter. No change in behavior from previous post. One thought...would it be possible to compile the DLL as a standalone exe rather than an FS module? It might be handy to be able to hang the PFC onto one of the clients and feed the flight control inputs to the server via the WideFS data stream. Cheerio
  21. Pete; I did some experimenting today...found a couple more really strange things about HT and processor affinity I can't fully explain. I restored a virgin copy of FS9.exe without the affinity mask. Then I assigned an affinity to each DLL in the modules folder separately using IMAGECFG, putting G2D, G3D, and Terrain onto vCPU1, and the others to vCPU0. With pfc.dll removed from the folder, FS9 starts running with both vCPUs at 100% and ~12fps. I then manually set affinity for FS9 in the task manager to CPU1, and it runs 100% on vCPU1 with minor activity on vCPU0, and frame rates go up to 20fps on average. Then...and this was a surprise...if I reset FS9 to run on both vCPUs, the load will then run shared equally across the vCPUs at around 50% with a lot of flux +/- around 15-20% on both sides...and frames remain at ~20fps. Then I repeat the experiment with pfc.dll running. Every time I go to both vCPUs with pfc.dll up & running, both virtual processors shoot up to 100% and frames drop back to around 12. Clearly something in pfc.dll is not living happily with whatever does the HT load sharing. I'm heading out to find a USB-serial converter shortly...I've been wanting one for a while anyway. Will advise how that goes later. Cheers
  22. Pete; I just dropped in a 3.06 GHz hyperthreading CPU into my system...had the most unpleasant surprise of seeing a sizeable decrease in performance compared to the Intel 2.8 GHz (non HT) that preceded it. I found this article in my research. http://support.microsoft.com/default.aspx?scid=kb;en-us;815227 It says that there's a known bug in the UnMapViewOfFile function in the WinXP kernel that causes performance degradation in Windows XP machines with SP1 installed and multiple logical processors (hyperthreading or SMP). As I recall, FSUIPC uses file mapped views. I'm calling Microsoft tomorrow to discuss the fix...not sure why, rather than posting the fix, they post a KB article that says "call us." Grrrr Regards
  23. I'm not sure why on some systems FS2004 seems to already have an affinity to run on a single vCPU. On mine, with FS2004 running I saw both vCPUs running at 100% before setting processor affinity. I feel certain that this is why some folks see a marked improvement, and others nothing. Just out of curiosity, was your system built with the HT CPU from the beginning, or was the CPU upgraded after the OS was first installed? Cheers
  24. I found the imagecfg.exe file here: http://users.aol.com/axcel216/xptoy.htm Cheers
  25. An even better way of constraining FS9 to run on a single virtual CPU on an HT CPU is using the Microsoft IMAGECFG utility (an older NT/2000 utility that works fine in XP -- do a google search). Command syntax (from an MS-DOS Command window): IMAGECFG -a 0x1 \fs9.exe This writes a processor affinity mask into the executable. 0x1 specifies virtual CPU 0, 0x2 specifies vCPU 1, and 0x3 uses both 0 & 1 (default). FS will always run on the specified virtual CPU(s) from that point on. I have done the same to the other utilities I run on the machine while FS is running, only restricting them to the opposite vCPU.

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.