blave

Pete, it's a mystery to me. One thing I didn't mention initially (because I didn't really think about it until the wee hours this morning) is that the wall wart that I used with the stack for years died at some point over the last few months, and so I'm now using another one that i repurposed (by reversing the polarity of the plug, since for some reason that only PFC knows they use a negative-tip scheme). This morning I was wondering if maybe the wart wasn't putting out enough juice and so the stack was on the hairy edge of almost working (and sometimes it *would* partially light up when I was in FSX). But now it works with that same wall wart, so.... HellIdonknow 8^) . The point is, it works now! --- BTW you may not recall this but I'm the guy that, way back when, asked if you could get the stack's "power" to be controlled by FSX's avionics switch. Lo and behold you did it in short order, and every time I turn on the stack with one of my GoFlight switches I think of that. Much appreciated! cheers, Dave.

I spent some time trying to find newer drivers for the Eight Buck Card, but had no luck. Actually Device Manager says that the two drivers that are associated with it are by Microsoft... So I took the back panel off of the PFC stack and disconnected the ribbon cable from the PC board that's on the back of the DME unit, which is what gives what I thought were spurious messages. Fired up the unit, and it worked fine (other than the DME section being dark of course -- but the messages were still being generated!). Plugged the ribbon cable back in, and it worked fine. Still works fine... I have no idea what I did other than re-connecting the serial cable to the back of the stack after re-attaching the back panel. Could all of this have been caused by some corrosion on the DB-9 connector pins? (rhetorical question) The messages are still generated, but perhaps that's just what the stack does. I don't recall it doing this before on my old system but until recently I hadn't touched FSX in quite a long time so maybe I just forgot. Pete, thanks for your assistance while I tried to get this sorted! cheers, Dave.

Hmmm, I guess I missed your post about BrainBoxes. I ordered a PCI-to-dual-RS232 card from Amazon (Eight bucks shipped!) a couple days ago, and it came today. It does exactly the same thing - repeating messages from the DME part of the stack, and all displays remain dark. Today I also tried the older FSUIPC and PFCSFX DLLs that are on my old WinXP gaming rig, with which the stack does work on that system, and that didn't make any difference. One thing I will note is that the first time I clicked through the optional "check equipment on startup" dialog that PFCSFX has, the display went from its normal "show the firmware datecode" mode to being completely dark, other than the PWR and TRANS LEDs. So I'll admit that I tried to Go Cheap on the PCI-RS232 board, but the fact that it does exactly the same thing as the USB > Serial dongle that I tried before makes me wonder if there isn't some other issue, possibly related to Win7? This is the first time I've run FSX on that OS. I only say that because the stack works fine with my old XP-based FSX system. thanks, Dave.

Pete, once again I am amazed at your quick reply... Do you ever sleep? After the stack is re-powered and FSX is restarted, I get the repeating 3 switch codes, as well as correct responses when I turn knobs or switch switches. Nothing seems to change that. I will buy a PCI serial port board on the weekend. BTW I will point out that your PFC instruction document strongly recommends a USB to serial converter gizmo, for WinXP -- perhaps that needs to be updated for Win7 in terms of NOT recommending a USB to serial thingy. I'll let you know how things turn out... cheers, Dave.

I just built a new gaming rig, and have spent some time trying to get my PFC stack to work with FSX with no luck. Here are the facts: the stack works fine with my old PC, which has a serial port built-in. Note that the FSUIPC and PFCFSX.DLL versions on that system are not current though (4.6 and 4.3 respectively) the new system (based on an Asus P8Z68 mobo) doesn't have a serial port, so I'm using a serial-to-USB adaptor that is listed in Device Manager as "Prolific USB-to-Serial Com Port (COM3)". I have used this adapter before, but not with the PFC stack. Windows 7 thinks it's working fine. new system has the latest FSUIPC and PFCFSX DLLs. When I enable the "Run connection tests at startup" in the PFC add-on dialog and restart FSX, the following "green check" messages appear: "FSUIPC4 okay. All options available: 4.800", "COM3 open okay", and "Okay!" next to "Avionics / radio stack connection". when I go to the Test tab in the PFC add-on dialog, I'm getting uncommanded messages: "E4 09 DME RMI = NAV1", "F4 07 DME mode2 = RMT", and "F4 00 DME mode1 = Off". Those three messages keep repeating over and over. If I press any button/twist any knob, these are reported correctly, including the slide switches that correspond to the uncommanded messsages. The stack's LED displays remains dark, or if I cycle power it will remain in the initialized mode that shows its firmware's date code. Initially I thought this was caused by the USB to serial dongle being defective, but I can't imagine how it could cause those three specific switch codes to happen and nothing else. Any ideas guys? Thanks, Dave B.

I have the avionics/RIC, but not the Cirrus console (sold it a long time ago). I think mine is older than yours, although I had PFC update it in 2001 or so. I don't normally use the RIC (I have GoFlight stuff to control those things), but I hooked mine up just now; my HDG and CRS/DG knobs work as expected, with the slow/fast messages being transmitted depending on how fast the knobs are turned. No glitching. However, I was surprised to see that my stack is putting out those extraneous DME messages as well, exactly as you describe! I'm not sure whether this is a hard/firmware problem or a PFCFSX one, but I have used the Test functionality of the PFC driver before, and don't recall getting that "noise". What I don't recall is if the last time I used it was in FS9. Back to the twitchy knobs thing: I'm going to make a wild a**ed guess and surmise that the encoders are dirty or defective. One thing you might try, although I don't know if this would involve some desoldering/soldering work, is to temporarily swap out one of the other encoders for either of the ones that are giving you trouble, and see if the twitchiness moves with the encoder. Also, make sure that the two cables (ribbon and "phone"-like) are tightly connected on both ends and that they're intact. Good luck, Dave B.

Clarification: FliteDeck is a superset of FliteMap in the sense that instead of only having a VFR sectional (moving) map capability, it can show low and high enroute maps, and more significantly instrument approach plates and airport diagrams. It has only very basic flight planning capabilities - ironically it's supposed to be used in conjunction with FliteStar (FliteMap without the moving map capability) and can import FliteStar/FliteMap plans. This doesn't really work for me as I (a) don't use FliteStar and (b) typically use the RXP 530 navigator's flight planning capabilities (since the latter doesn't have any kind of import capability). If I'm going to FS's ATC (which isn't very often) then I export the 530's plan to FS as a .pln file. At any rate, thanks for your reply and explanation. I knew it was a long shot but thought I'd try. BTW while I'm here - I sort of accidentally discovered the new? mouse macro capability in FSUIPC about a month ago, and for me it's the most significant enhancement to the program in a long time. Thanks for doing that. cheers, Dave.

I am using Jeppesen FliteDeck v3.2 (a few years old - 2005 I think), which is their IFR enroute/approach chart moving map application (it's sort of a superset of FliteMap). It's running on a 2nd PC that I drive via GPSOUT and a serial cable. I was thumbing through its manual recently and came across a feature that I had not been aware of: "When connecting FliteDeck to a GPS unit that outputs route information, FliteDeck automatically uses the active route from the GPS receiver." That feature would be of great use to me if I could use it - currently I have to separately key in my flight plan to FliteDeck to emulate the FP that I have entered in FSX if I want things to match up. I have google'd high and low and can find no other technical information on the specifics of what the program is expecting, but some research of the NMEA format leads me to believe that this feature is using the RTE message: RTE - RTE is sent to indicate the names of the waypoints used in an active route. There are two types of RTE sentences. This route sentence can list all of the waypoints in the entire route or it can list only those still ahead. Because an NMEA sentence is limited to 80 characters there may need to be multiple sentences to identify all of the waypoints. The data about the waypoints themselves will be sent in subsequent WPL sentences which will be sent in future cycles of the NMEA data. $GPRTE,2,1,c,0,W3IWI,DRIVWY,32CEDR,32-29,32BKLD,32-I95,32-US1,BW-32,BW-198*69 Where: RTE Waypoints in active route 2 total number of sentences needed for full data 1 this is sentence 1 of 2 c Type c = complete list of waypoints in this route w = first listed waypoint is start of current leg 0 Route identifier W3IWI,... Waypoint identifiers (names) *69 checksum So my question is, is there any possibility of enhancing GPSOUT to output the FS flight plan using this protocol? thanks, Dave Blevins.

[quote name="I bet it didn't start FliteStar either' date=' eh? To make shortcuts I just use the mouse, drag the EXE to the desktop bu press the ALT key before releasing. I think that works with all versions of Windows. Regards, Pete[/quote] That's the weird thing - it DID start FliteStar, which seemed to work. re: Shortcuts - I always used to do it the way you describe, but the Pin To can be done with two clicks and no dragging. You see, I'm really lazy! dB.

SOLVED. But, I must say that my problem was due to something I've never seen before. You said to check the shortcut's folder settings. Well, it turns out that when I did a WinXP "Pin To Start Menu" action on FStarRC.exe, it copied the executable to the Start menu, rather than a shortcut. So, of course it couldn't find the runway file. I have used the Pin To Start Menu many times and have never seen this happen before with other executables. Anyway, to work around this, I created a shortcut in the Flitestar folder and then pinned that to the Start menu. Now, all is well, and thanks for *another* useful program to enhance my FS experience. cheers, dB.

I have never used FStarRC before - just tried to get it working for the first time yesterday. I copied all of the files (except "if you cannot see the DLL.txt") into the FliteStar directory... BTW I don't have FliteMap, just the subset FliteStar product. I just updated it with the updater available on the Jepp site today, to the same build that you have.... Still having the problem. I know you're quite busy supporting all of the excellent utilities that you provide, so I don't want to take up too much of your time on this. I can get around this by using one of the FS2004-compatible planners... But I have to admit that when I found out I could use the planner I use for RW flying with FS2004 as well, I got kind of excited :D . cheers, Dave Blevins

Happy new year Pete, When I do a print of the flight plan in FliteStar, I get the following error in the APL file: "Can't find or open the runways database (FStarRC.rws)" I have confirmed that that file exists in my FliteStar directory, along with the other FStarRC files. Attempting to open the .rws file in Wordpad shows binary-looking nonsense, so I presume it is in fact binary. The FliteStar version is 9.029, and it's the "IFR" version. Thanks, Dave Blevins

The FSGarmin and FSFlightMax support pages can be found in the forums at Avsim.com. There you will find FAQs and links to the files that are required, including the key generators that will register the software. I spent some time on both programs last year and have them working on a 2nd PC just fine. It takes some time to get working - I spent quite a bit of time searching the forums for stuff - but that paid off. If you would like my help I'd be happy to assist, but not in this forum - post something in the forum at Avsim and I or someone else will help out. cheers, Dave Blevins

Hi Pete, Welcome back. Sorry, I haven't monitored the forum for a few days... I did some add'l testing tonight. I have a *little* bit more data. My setup includes the PFC avionics stack, and several GoFlight modules including the MCP autopilot. So I just fired up the Learjet and did a quick flight. This is what I've found: * I renamed FSUIPC.INI to somethng else, so that FS does not load it. I left PFC.INI alone. * I started up FS2004 and loaded the Learjet. (Note: the avionics are the RealityXP JetLine4 instruments, but I have noticed the described behavior with other non-JL4-enabled aircraft as well. * I set the GoFlight autopilot up for hdg/altitude/speed targets. * I press the PFC stack's Direct To button - which is theoretically not programmed to anything since the FSUIPC.INI file has been renamed. HOWEVER, I note that pressing this button disables the IAS/Mach Hold mode of the autopilot - i.e. the HOLD LED on the GoFlight MCP turns off. This also results in the throttle being backed off quite a bit. * pressing the GPS ON/OFF and NAV/GPS buttons also do things to the MCP, e.g. switch the SEL button from IAS to Mach, etc. (update: I just tried it with the stock C172 as well. Lifting off in the 172, with full power (but without the autopilot being engaged), and then pressing the Direct To button on the PFC stack causes the C172's throttle to go to idle.) This anomalous behavior seems to be limited to just a few buttons on the PFC stack - i.e. almost like just a few keycodes are getting duplicated or something. The NAV/GPS, ON/OFF, Direct To, and maybe (I didn't test this tonight) the ENT buttons on the PFC stack are the only misbehaving ones that I'm aware of. The only thing I can surmise at this point is that the addition of the GoFlight programming has somehow resulted in some heretofore unrealized problem in the PFC panel code - which is not dependent on how I have those buttons programmed since I'm starting out with a fresh FSUIPC.INI. Let me know if you need more details or testing on my part. I have attached my current FSUIPC.INI (after renaming it, running FS2004, and then exiting FS) to the end of this post. cheers, dB. I've been trying to work out what could be going on with your system. You say: ... but I don't see how this can possibly be FSUIPC because by using a new default FSUIPC INI you most definitely have go no PFC buttons programmed in its Buttons page. Frank's problem is entirely different and I think I've found that. By default, without Project Magenta's MCP running, the GPS buttons in PFC do nothing -- they aren't even all available for you to program. In fact the ones you mention (NAV-GPS, D->, MSG, ON-OFF) are only programmable in FSUIPC -- in PFC with no PM running they are dead, ignored. In order to understand what is happening on your system I need to know rather more about what you've got installed, what is running, what you've programmed. Please also check those buttons in PFC test mode. If the PM MCP is running, then NAV/GPS toggles "N1" (TO/GA by default in FS) which could cut the throttle, ON/OFF is the IAS/MACH selector, D-> sets A/P SPD mode and MSG is VNAV. None of these latter ones would do anything noticeable if the A/P is off. Erthis is even more puzzling, as there are no changes in FSUIPC which would affect PFC. They are different programs. I really need a lot more help understanding this, please. Regards, Pete [General] History=U41XQTODX7T1DRHAYD5PS WindSmoothing=No WhiteMessages=No ThrottleSyncAll=No GraduatedVisibility=No LowerVisAltitude=6000 UpperVisAltitude=25000 UpperVisibility=6000 GenerateCirrus=Yes WindShearSharp=No UpperWindGusts=No ExtendMetarMaxVis=Yes PatchSimApAlt=Yes AutoClearWeather=Yes ExtendTopWind=Yes WindSmoothness=5 SmoothPressure=No PressureSmoothness=5 SmoothVisibility=No VisibilitySmoothness=2 MaxSurfaceWind=0 WindLimitLevel=200 WindDiscardLevel=400 WindAjustAltitude=No WindAjustAltitudeBy=2000 MinimumVisibility=0 MaximumVisibilityFewClouds=0 MaximumVisibility=0 MaximumVisibilityOvercast=0 MaximumVisibilityRainy=0 OneCloudLayer=No ThinClouds=No ThinThunderClouds=No CloudThinness=1000 ThunderCloudThinness=10000 CloudTurbulence=No CloudIcing=No WindTurbulence=No SuppressAllGusts=No ExternalOptionControl=Yes AutoTuneADF=No KeepFS98CloudCover=No ShowPMcontrols=No MagicBattery=No RudderSpikeRemoval=No ElevatorSpikeRemoval=No AileronSpikeRemoval=No ReversedElevatorTrim=No TrapUserInterrupt=Yes NavFreq50KHz=No ClockSync=No SmoothIAS=Yes SetVisUpperAlt=No VisUpperAltLimit=6000 MaxIce=3 SuppressCloudTurbulence=No SuppressWindTurbulence=No SpoilerIncrement=512 TCASid=Flight TCASrange=40 TrafficScanPerFrame=10 AxisCalibration=No CentredDialogue=Yes ClearWeatherDynamics=Yes OwnWeatherChanges=No FixWindows=No FixControlAccel=No WeatherReadInterval=4 MoveBGLvariables=Yes MainMenu=&Modules SubMenu=&FSUIPC ... [JoystickCalibration] FlapsSetControl=0 ReverserControl=66292 MaxThrottleForReverser=0 AileronTrimControl=0 RudderTrimControl=0 .end post.

I saw the same thing. The only way I know to get around this is to manually edit the FSUIPC.ini file. I have to do this anyway since I'm using the RealityXP "unit selector" methodology, where you send two ctrl-shift-key events - the first to select a particular instrument (or group of instruments), and the second to "press the button". But anyway, open up your .ini file and find the line that corresponds to what you tried to set up in the FSUIPC GUI, and then manually change the keycode to what you want. You'll need to use the FSUIPC Guide For Advanced Users, which has the keycode mapping numbers. Good luck, Dave Blevins

Frank, Somehow I knew you'd be a respondent to my post :) Thanks for your info - it does look like something has gone wonky with the driver(s). I do have prior versions of both programs (although I was able to fix this by loading only an older version of FSUIPC) so I'm OK. (I do think my problem is slightly different, as (to my knowledge) the GPS buttons don't do anything at all in FS unless you custom-program them. I was unable to determine what's unique about those four buttons from a keycode or whatever standpoint, but I'll leave it to Pete from here on out.) BTW I'm doing the same thing as you w.r.t. the GPS section, except I use the RealityXP 530XP. For a while I had the FS9 GPS set up with the same assignments, and it was interesting to have them both displayed and see the divergence in the two GPS's behavior.... cheers, dB.

I believe you're referring to the GNS530 add-on that was developed by FSAvionics, which is now out of business. Pete had nothing to do with that product to my knowledge. There is a support forum for the two FSAvionics products at avsim.com... At one time I had it working with FS2004 but I switched to RealityXP's similar product due to its much better integration - e.g. it works with the autopilot the way it should. But at any rate you should check that forum to see if something there can help you out. Dave Blevins

I know that Pete is taking a well-deserved vacation right now, but I thought I'd post this to see if anyone else has the same issue... I am having a problem that I *believe* is a new bug in version 3.20/3.201. Here is what I see: 1. rename fsuipc.ini to something else to ensure that FSUIPC.DLL creates a fresh one. 2. start FS2004 with (e.g.) the Baron; but any airplane should do. 3. apply full throttle 4. press any of these buttons in the GPS section of the avionics panel: NAV-GPS, D->, MSG, ON-OFF. 5. on my system, the throttle(s) go to zero - as if a "throttle cut" command has been sent to FS2004. At first I thought it was the keystroke generation assignments I had set up causing this, but after lots of headscratching and troubleshooting, I finally got to the point of doing step (1) first, so as to eliminate any custom FSUIPC configuration. It still does what I describe, so I wanted to see if any other PFC avionics users are seeing this behavior. Reverting back to FSUIPC 3.135 eliminates this problem, but then I lose the new GoFlight capabilities... Is anyone else seeing this anomaly? thx, Dave Blevins

As I posted over on Avsim, I won't be able to try out this new functionality until I return home from Hawaii on the 18th, but this is at first blush great news. I have a number of GF modules, and I had a few issues with some of them (e.g. the RP48's rotaries could not generate keystrokes, limiting their usefulness, and also the LGT's landing gear lever could not actuate the Flight1 Meridian's landing gear due to the latter's customized programming). If I'm reading 3.2's capabilities correctly these things can be addressed, as well as some other niggles that I've had with various things, and this will greatly improve the usability of my GF stuff. The ability to save settings per-aircraft is also very welcome. Thanks, Pete. You are hereby nominated for FS Guy of the Year for 2004. The year is young, but in my mind this crown already has an owner. Dave Blevins Dave Blevins

Sorry, but I cannot undertake to support every add-on. I don't even have that one, and I'm afraid I am not particularly on excellent terms with its creator. No problem. My post was really out of curiousity. (But I have to admit, your last comment is intriguing... None of my beeswax though.) Please try the FS2004 GPS and see if you get the same. I'm not sure what is supposed to happen when the FS A/P is following the GPS rather than the NAV indications, but if there is something obvious I can look at making a change --- probably merely detecting that the GPS is driving the A/P, not the NAV and so not activating any LEDs at all. I did fiddle a bit with the FS GPS before making my post, but ran out of patience with it. As far as I can tell it does the same thing, albeit perhaps not all the time. Like I said, this is a very very tiny niggle, and my PFC avionics stack is working fine, thanks to many enhancements you've made over the last few months (some based on my own requests). The blinking NAV light is very "livable". cheers, dB. P.S. I'm going to make every effort to bother you less here, so that you can fly more! I realized recently how much time it must take for you to support this forum, and I would rather not be a contributor to you boring holes in the virtual sky any less than you would otherwise.

Now I'm really getting picky... And this is no big deal but I'm if nothing else curious as to why this happens. When I am using the RealityXP 530XP Garmin GPS add-on, and have my autopilot set to NAV and the nav source set to GPS, the NAV LED on the panel continually flashes, which I believe means that PFC.DLL thinks that the autopilot is still not locked to the nav guidance signal. Everything works as expected, other than the LED. Thanks, Dave Blevins

OK, I guess I was not using the correct terminology - I have always known that your driver doesn't know about the active radio. But, effectively the on-off buttons acted as Active Radio Select buttons, and it worked perfectly in the FS2000 (or was it 98?) single COM radio world, and worked (past tense - see below) fine in 2002/2004 as well if one didn't need to access those versions' COM2 as a true second radio. I just got used to thinking of those buttons as the equivalent to what is found in a real aircraft's audio panel. I just checked the version you sent me today, and unless I am being incredibly dense it's still not working the way it did prior to 1.8 with the "COM2 radio selectable into FS" option checked. (I noted that you did get rid of the other anomalous behavior where only the standby side of COM1 was lit in some cases, BTW.) What I mean is that, with the box checked, successive presses of the COM ON/OFF switches will always result in turning off the respective COM radio at some point. In prior versions, if you only ever pressed either button once before pressing the other, then they worked quite well as "audio panel" buttons and neither radio was ever turned off unless you pressed its ON/OFF button more than once in succession. Now, it is impossible to switch from one radio to the other (after the first time) without turning one off. I was initially baffled because I forgot to uncheck the box with version 1.8 to get "true" COM1/COM2 radios. That is how I found the behavior which you partially addressed in the new version today. But - as I stated above - it still doesn't behave exactly like pre-1.8 versions. That doesn't really matter to me anymore since you now support FS's COM2, but it might to others. Well once again you're the man of the hour, but please don't trade precious sleep time for this little thing 8) . Cheers, dB. EDIT - upon reading one of my posts earlier in this thread , I realize I got a little mixed up in describing the two modes that now exist in 1.8x. To be perfectly clear, as of 1.812 the Unchecked mode is working perfectly, with full COM1/COM2 support. The Checked mode might need a little more attention if it's to exactly emulate what it did prior to 1.8. But if no-one complains, perhaps it doesn't matter! P.S. You might be able to help me with one teeny thing - I'm trying to assign a PFC button (the ident button, since it doesn't do anything in FS) to set the transponder to "1200". I spent about a half hour trying to decipher how the Parameter that can be specified on FSUIPC's Buttons tab gets translated into the transponder code, but I just couldn't figure it out. There's some base 2 stuff going on, but when I saw that a parameter of "10" means "2" on the transponder (which makes sense in binary representation) while a parameter of 100 means 64 (huh?) I pretty much gave up. So, what's the magic number that results in "1200" on the display? (BTW not being able to sort this out makes me wonder how I ever got through engineering school. :x )

(* or perhaps almost all - I believe that autopilots are not wired through the avionics switch in GA aircraft, so perhaps that section should remain lit as it does on the GoFlight MCP autopilot module whenever the Master switch is on.) Really? Seems unlikely? Not so sure about that as you are. The avionics include the very NAV radios which some of the A/P buttons connect to and operate from. If the entire stack is a Bendix King, as simulated, then I think you'll find it all gets its power through the same switches. Ah (after checking a couple of my POHs), I think you're right. Not sure where I got that. ...Exactly the same, if you have that option selected and you are using an Avionics stack and don't have Jetliner selected as the console. The only difference now is that by "selected into FS" is meant "selected as COM1", as the other one is also now selected into FS, but as COM2. Really, for more realistic use of the Avionics stack you should turn the option off and just use COM1 as COM1 and COM2 as COM2. I only left the swapping business in in case folks were using COM2 as a sort of storehouse of additional standby frequencies for use with, say Radar Contact or Squawkbox. Don't I explain this well enough? It turns out that I had the "COM2 radio selectable into FS" box checked. I didn't realize that the new "true COM2" functionality doesn't require that. But, see below... What, what? Please tell me how to make that happen -- it must be a bug!Here both standby and active frequencies are always both displayed, except in the "off" part of the loop where neither of them have anything displayed. There should NEVER be a case where only half of the radio is on and the other half off! I will need exact steps to reproduce this please, as I doesn't happen whatever I do here. Maybe I shall need your PFC INI file too. Here is the behavior I'm seeing: 1. with the "COM2 radio selectable into FS" box unchecked, the ON/OFF buttons do exactly one thing - turn the respective COM/NAV radio display "off". Unlike before, the buttons can't be used to select the active xmit radio. As I said before, this isn't important to *me* since I now have GoFlight buttons for COM1 and COM2 xmit selection, but it's not behaving the way it did prior to the TruCOM2 technology being implemented 8^) . 2. with the box checked, here is the sequence of what happens: a. press COM1 on/off button - COM1 turns off b. press COM1 again - standby freq window ONLY is lit, with the standby freq displayed there c. press COM1 again - active freq display is restored Then it goes back to "a" when the button is pressed again. Now, here's the behavior when the COM2 ON/OFF button is pressed - and it gets more interesting since the behavior depends on the state of COM1: - with COM1 off, pressing the COM2 button turns COM2 (only - not the NAV side) off. Also - the first time it's pressed, the freq sets are swapped between COM1 and COM2 - with COM1 in the "b" state above, pressing COM2 causes the freq sets of the radios to be swapped, and COM1 is lit on both sides. (Pressing COM1's button at this point re-swaps the freq sets again.) - with COM1 in the "c" state above: -- pressing COM2 turns COM2's displays off; -- pressing COM2 again turns COM2 back on *and* swaps the freq sets between the radios; -- pressing COM2 a third time swaps the sets back again; -- and then pressing COM2 again loops back to the COM2 displays being off So it sure seems that something is whacko in this new code. I am running FSUIPC 3.125 and PFC 1.81. My PFC.DLL is at the end of this message. The aircraft used to determine the behavior described is the stock C172 in the ugly red paintjob. Oh, and I verified that none of the buttons/knobs in the COM sections have been assigned non-standard functions in FSUIPC. Let me know if you need any more info. cheers, dB ---begin PFC.DLL--- [Connection] Port=COM1 [General] OptionsSet=19081423,2 QuadrantSet=P1N EnabledQuads=1 ADFmode=0 COMactive=1 COMoff=0 Radials=0 ElevatorTrimUnit=16 ElevatorTrimDelay=20 ElevatorTrimMult=8 MaxThrottleForReverser=0 COM1sb=8592 COM1na=8192 COM2sb=6544 COM2na=9072 NAV1sb=4192 NAV2sb=2400 ADFsb=1104 ADFxsb=256 DME=2048 CentredDialogue=Yes AxisSmoothTime=500 SpoilerFlightPercent=75 [buttonAssignments] ListAllControls=Yes ListPMControls=No List767PICControls=No Yoke0=0,0,1 Yoke1=0,0,1 Yoke2=0,0,0 Yoke3=0,0,0 Yoke5=0,0,0 Yoke6=0,0,1 Yoke7=0,0,1 Yoke8=0,0,1 Yoke9=0,0,1 Yoke10=0,0,0 Yoke11=0,0,0 Avionics0=0,0,9 Avionics1=0,0,9 Avionics2=0,0,0 Avionics3=0,0,0 Avionics4=0,0,0 Avionics5=0,0,0 Avionics6=0,0,0 Avionics7=0,0,0 Avionics8=0,0,0 Avionics9=0,0,0 Avionics10=0,0,0 Avionics11=0,0,0 Console0=66299,66299,9 Console1=66298,66298,9 Console2=32,32,0 JetLiner0=0,0,0 JetLiner1=0,0,0 JetLiner2=0,0,0 JetLiner3=75,75,0 [ThrottleQuadrants] P1N-0=5,5,20,20,56,72,108,128 P1N-4=5,13,20,20,56,72,108,128 P1-0=5,31,20,20,56,72,108,108 P1-2=5,5,20,20,56,72,108,108 P1-4=5,13,20,20,56,72,108,108 P1H-0=5,5,20,20,56,72,108,108 P1H-2=5,21,20,20,56,72,108,108 P1H-4=5,13,20,20,56,72,108,108 P2-0=5,5,20,20,56,72,108,108 P2-1=5,6,20,20,56,72,108,108 P2-2=5,21,20,20,56,72,108,108 P2-3=5,22,20,20,56,72,108,108 P2-4=5,13,20,20,56,72,108,108 P2-5=5,14,20,20,56,72,108,108 P2B-0=5,21,20,20,56,72,108,108 P2B-1=5,22,20,20,56,72,108,108 P2B-2=5,5,20,20,56,72,108,108 P2B-3=5,6,20,20,56,72,108,108 P2B-4=5,13,20,20,56,72,108,108 P2B-5=5,14,20,20,56,72,108,108 T2-0=5,9,20,20,28,44,108,108 T2-1=5,10,20,20,28,44,108,108 T2-2=5,25,20,20,40,56,108,108 T2-3=5,26,20,20,40,56,108,108 T2-4=5,17,20,20,54,70,108,108 T2-5=5,18,20,20,54,70,108,108 J2-0=5,30,20,20,35,35,108,108 J2-2=5,5,20,20,56,72,108,108 J2-3=5,6,20,20,56,72,108,108 J2-5=5,32,20,20,56,72,108,108 J3-0=5,30,20,20,35,35,108,108 J3-1=5,5,20,20,56,72,108,108 J3-2=5,6,20,20,56,72,108,108 J3-3=5,7,20,20,56,72,108,108 J3-5=5,32,20,20,56,72,108,108 J4-0=5,30,20,20,35,35,108,108 J4-1=5,5,20,20,56,72,108,108 J4-2=5,6,20,20,56,72,108,108 J4-3=5,7,20,20,56,72,108,108 J4-4=5,8,20,20,56,72,108,108 J4-5=5,32,20,20,56,72,108,108 J2N-0=5,49,0,10,20,88,98,108 J2N-1=5,5,20,20,64,64,108,108 J2N-2=5,46,20,20,64,64,108,108 J2N-3=5,47,20,20,64,64,108,108 J2N-4=5,6,20,20,64,64,108,108 J2N-5=5,48,0,7,2,38,110,116,7,26,38,50,62,74,86,98 [FlightControls] Ailerons=4,0,20,20,56,72,108,255 Elevator=4,1,20,20,56,72,108,255 Rudder=5,2,20,20,56,72,108,255 LeftBrake=5,3,20,20,56,72,108,128 RightBrake=5,4,20,20,56,72,108,128 --end PFC.DLL---

Thanks for the responses gentlemen. I don't use the Cirrus II console due to desk space reasons (anyone wanna buy mine?); instead I have a set of GoFlight stuff including two of the T8 toggle switch modules. I have (amongst other power switches) a "Avionics Master" switch on one of the T8s, which is "tied" to the on-screen av power switch that is in most or all FS2004 aircraft. So what I'm asking for is for all* of the displays on the PFC stack to be blanked whenever that FS switch is off. (* or perhaps almost all - I believe that autopilots are not wired through the avionics switch in GA aircraft, so perhaps that section should remain lit as it does on the GoFlight MCP autopilot module whenever the Master switch is on.) That all said, you (Pete) mention in one of your responses that this would be messier than you thought it would be... As I said in the original post it's a minor thing - it adds to the realism and immersiveness, but in the end there are probably more important enhancements to be made. I'm just tickled to death that you've added the COM2 support. There is very little else I could want in the PFC driver, which is why I'm getting down to the niggly stuff 8^) . --- Pete, regarding what I considered to be a misplaced section in the PDF document - In "Avionics Options - COM radios" - i.e. the section after the RIC discussion, there is this last sentence before the "NAV radios" part: "The on/off switch cycles between these two and off." But then later on when you're talking about the specific avionics option checkboxes, there is a sentence after the "Transponder ident light flashes" portion that seems be be "hung in space", and I believe you meant it to go after the sentence I quoted above: "However, the complete action of the On/Off button depends on the option labelled “"COM2 radio selectable into FS" (with the Avionics Stack) or “COM on/off swaps COM1/2 display" (with the Jetliner on FS2002 and FS2004).". That's what I was talking about. --- By the way, coincidentally I'm still confused about how these on/off buttons on the COM radios work now. In versions prior to 1.8, they could be used to select the active radio. However, in 1.8x I can't quite figure out what's going on. At one point of cycling through the modes by pressing one or the other of these buttons, only one of the displays on COM1 has anything in it. At another point the standby/active frequency sets get swapped between COM1 and COM2. It's not a big deal for me personally since I'm using some GoFlight buttons to select my current radio, so I don't use those buttons anymore, but it doesn't seem to behave quite like what the documentation describes. Thanks for the excellent support, Dave Blevins

This is a little thing, but it would be neat if the PFC avionics stack's displays could be controlled by FS2004's Avionics Power switch, so that the displays are blanked out when that switch is off. BTW thanks for the COM2 enhancement in v1.8! It rocks. (However, note that in the PDF file that accompanies version 1.81, there is a misplaced text section that should be with the COM2 discussion, but somehow ended up in the "The Avionics Options" section later on. It looks like a cut/paste error.) Thanks for listening, Dave Blevins