airforce2

Pete; When I made the switch to PFC 1.90, the throttle quad was no longer recognized. After several unsuccessful FS restarts I added the line Speed=9600 in the Connection section of PFC.INI, and that cured the problem. It's odd, because the driver removed that line when it re-wrote PFC.ini, but the driver continues to work now without it. Is it possible that, with the new logic arising from use of both 9k6 and 19k2 PFC devices, the port config is not being positively written under some circumstances when using a 9k6 device? May be worthwhile to allow explicit port speed assignment (Speed=9600 as well as 19200) to remain in the ini. Cheers

I'd be taking a hard look at the timing settings in WideClient if I saw 94% CPU ute rate. Cheers Bob

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

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!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

RVDT = rotary variable differential transducer

"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).

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