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