westes

I'm seeing a strange behavior when using GPSOut that I cannot quite explain. I have GPSOut set to update COM2 every one second. What I see instead is while FS2004 is running every one second there is a NetBIOS broadcast on port 138 of my network. I can't be sure if this is GPSOut, FSUIPC, or FS2004 itself, and I will of course test that in more detail this weekend. The activity instantly starts when FS2004 loads and instantly stops when FS2004 exits. The timing of every one second however does seem suspicious given what GPSOut is set to do. Can you think of any reason that GPSOut would need to learn all of the machine names on the network, or why the host OS (Windows XP) might try to do this as a side effect to something else GPSOut does? I couldn't detect any serial output (yes I used crossover cable), but I have a slightly more complex setup as well that will need to be debugged over time. For now, I'm quite anxious to just better understand this strange NetBIOS behavior.

Can GPSOut with the COM port set to WideFS work with multiple listeners? I want more than one moving map program on different computers to use the GPSOut signal. Can WideFS act as a server to two different ethernet segments on the same server computer?

I never could get the Twin Piston quadrant to behave like a turbine quadrant, even when I selected Turbine Quadrant. So I went out and purchased the PFC Turbine Quadrant (ouch, not cheap). Can you explain what the middle settings for the calibration mean? I did read the documentation. The documentation for calibration of a quadrant simply refers you back to the calibration of the yoke section. The behavior I see with the Turbine Quadrant installed and the Turbine Quadrant selected in software, is that the power behaves properly, but I cannot get the props to feather when I move them to the red feather section of the quadrant. I realize I must recalibrate but don't understand specifically how calibration of feather works. No amount of recalibration so far has succeeded in getting the feather control to work.

I want to feed a single NMEA stream from the computer running FS2004 to multiple devices that provide moving maps. Doing this with hardwired serial cables doesn't scale well. I thought that your GPSOut working together with the WideFS / MixW programs allowed remote devices to use virtual serial ports to acquire the NMEA signal. You have 90% of the solution done, and someone just needs to adapt the code you already have to the Mobile 5.0 environment. I don't understand why anyone should need to write clients and servers that are proprietary between Mobile 5.0 and the FSUIPC computer. Obviously the PDA application guys are never going to do that because their target has always been general aviation and not flight simulation.

Is there any chance we could convince you to support GPSOut and WideFS and MixW on PDAs running Windows Mobile 5.0? Because GPSOut can now provide NMEA standard GPS on the local serial port of the PDA, supporting these interraces would now allow all of the commercial PDA software that exists for general aviation to be used for FS2004! Doing this over a wireless TCP network without any clumsy serial cabling would greatly improve the utility and ease of setup of such devices.

This may be another "go read the manual" question, but how do I get the lower range of the throttle to go into the negative part of the throttle area, as would be appropriate for a turbine prop or jet engine in reverse?

Is there any trick I can use to make the PFC Twin Piston Quadrant behave like the Twin Turbine Quadrant, specifically to make reverse thrust enabled at the low end of the throttle scale?

Let's put some numbers behind my statements to help clarify things. Words like "jumping" and "fluctating" or "jittery" don't get at things precisely. I measure from the faceplate of the Cirrus console up the silver metal column to the start of the back of the Mooney style yoke at 2 1/4 inches. A pull of the yoke to its full extension gives a measurement of 3 3/4 inches. So the maximum I can deflect it in that direction is a mere 1 1/2 inches. On a typical descent, I am pulling the yoke maybe 1/4 of one inch. So if one wants to speak about things in linear terms, I am using about 1/6 th of the total possible movement of the yoke. That relatively minor 1/4 inch deflection will in some cases give me 1000 feet / minute of climb (during a descent that I want to stabilize at around (-700) feet / minute). In other cases the 1/4 inch deflection gives a 500 feet / minute climb. So, first, there is no consistency in the result I get, which makes it very very hard to stabilize my approaches, and second the absolute response to very small deflections seems in some cases absurdly too high. I will try 1.998, but could you point me to where I set these things: 1) Linear response 2) S curves

I finally have Peter's PFC drivers more or less working with a PFC Cirrus II Console. The most serious remaining problem is that when I am pulling up on the yoke or releasing it, the sensitivity is ridiculously too high. On an approach in a King Air to Telluride a very slight tug on the PFC yoke gave an altitude gain of 1000 feet and gently releasing this would bounce between descents of 100 and 2000 feet. It was very very difficult to control and did not behave as you would expect a yoke to behave. I saw a substantial improvement when I checked the "Filter" checkbox, but sensitivity was still set way too high. With a USB-based device, I could adjust sensitivity in FS2004 directly. Since this is a serial console, I don't see a way to control sensitivity in either FS2004 or in the PFC drivers. Is there a trick to adjusting this?

I went through this sequence, and now the quadrant works automatically on startup: 1) I deleted PFC.INI 2) I started FS2004. The quadrant was not utilized. I configured in PFC UI the one quadrant that I have available. No "Assign to Aircraft" button appeared on the quadrant tab. Quadrant would not activate in FS2004 even after hitting OK in PFC UI. Just a side note: as soon as I deleted PFC.INI and restarted FS2004, immediately FSUIPC reports it is not registered! Sure enough, FSUIPC is not registered and I re-registered it and registration was accepted. 3) I restarted FS2004. Still no quadrant is utilized. I opened PFC UI and went to quadrant tab. Now "Assign to Aircraft" appears. I selected this. Quadrant now works. 4) I restarted FS2004. Now the quadrant is auto selected and works right away, and I didn't have to start PFC UI. 5) What is interesting, at this point when I go to the "Test" tab in the PFC UI, I don't see any activity at all when I move the yoke or any part of quadrant. However all of those controls do work inside FS2004. I don't understand why I am the only person out of thousands with the good luck to see all this odd behavior. In any case, it now works, and I'll enjoy that while it lasts. I appreciate your ideas as they did get me to a working state I can live with.

What's a "throttle type"? Do you mean quadrant? Are you using automatic quadrant assignment (front page)? Have you made sure you have only enabled those quadrants you are actually using? Each quadrant calibration page has an enabling checkbox (top left). Only those you enable can be used. If you want specific quadrants with specific aircraft you can enable them and click the "Assign to Aircraft". By throttle I meant quadrant, sorry for sloppy terminology. I did read all parts of the manual related to quadrant selection and quadrant calibration. I finally got the quadrant to work, but it was quite buggy and required a number of repetitions through the PFC user interface. Miscellaneous observations: 1) When I start up with Cessna 182, no quadrant is active. I must always enter the PFC UI and do an "Assign to Aircraft" operation before I can get it to work. After exiting FS2004 9.1, here is the relevant line I find for quadrant assignments in PFC.INI for the 182: Cessna_Skylane_182S_Paint2=P2 Which throttle should that be assigning? 2) The PFC UI kept insisting on activating the Single Throttle Carburated quadrant (the first one on the list of quadrants). I kept disabling it on the quadrants page and then re-entering the PFC UI only to see it re-enabled and selected again. After much back and forth I got it permanently disabled and now my preferred throttle is the only one that is Active, and I am at least able to manually assign it to the aircraft each time I restart FS2004. I still am not able to get the quadrant to just assign and work automatically when I start FS2004. It always takes at least one trip to the UI. Regarding PFC.LOG, as I said in my post I could not attach it, and instead I made it available at the URL I posted. The ZIP file is large because it contains both the tiny PFC.INI and the large PFC.LOG. The PFC.LOG is large because I left logging running during a long flight. Should I be concerned about the buffer overflow messages in that log?

Okay, I am using the Interim release PFC 1.997 and 3.536, and I just duplicated the same problem I am having getting PFC Cirrus II throttle and yoke to operate correctly. In the PFC user interface, I am able to see the yoke and throttle movement reflected in the appropriate tabs, and both kinds of controls generate data on the test tab. You say that "automatic calibration" works well, but is there something explicit I must do to enable this mode? The bottom line is that I see the control movements reflected in the PFC UI, but as soon as I exit neither yoke nor throttles work inside the default Microsoft Cessna 182 or 172 implementations. On other occasions, I have gotten the throttle to operate, but not the prop control. No matter how many times I enter into the PFC UI and set the throttle type, it always seems to overrid my selection the next time I enter the PFC UI. There is something really basic here I'm just not getting. I am attaching PFC.INI and PFC.LOG per your request, but they were too large to make attachments here so I put them here: http://pages.uschw.com/misc/pfc/ I do note a lot of messages in there about buffer overflows. Maybe that is related to this problem?

After a long struggle, I have the Cirrus II console sending its yoke data to your PFC 1.92 module. It is badly out of calibration, but putting that aside now how do I get aircraft to actually use this? The PFC module sees movement of the yoke but when I load Carenado's T206, the controls on the Cirrus are not registering to the aircraft. Is there some magic switch that passes all of this data through PFC onto the aircraft?

Wow, can't believe you have a network connected computer not running Windows Firewall. In any case, In any case, I'm dealing with the *server* part of the firewall, and I'm telling it what applications to give free reign on the system as a server. You don't have a wideserver.exe, so I can't specify that. I tried FS2004, but that didn't solve it. I'll have to debug this at the TCP or UDP port level. What port(s) does WideClient on the remote machine try to connect to on the server? Are these UDP or TCP connections?

I use Wideclient on a remote computer. How should I set up Windows Firewall on the computer running FS2004 to allow the incoming connection by WideClient to WideServer.dll? I tried to authorize incoming connections to Flight Simulator itself, but that didn't work. I cannot select WideServer.dll. Firewall wants an EXE.

I have a Cirrus II console from PFC with a mooney yoke, some cockpit buttons, and a Barron throttle. All of this is on COM4 under Windows XP and running FS2004 9.1. When I start up the PFC configuration software, it "sees" movement on the throttles, but none of the movements on the Yoke appear to do anything. How can we determine whether the yoke is actually sending you any data?

I see what happened. Sorry, still learning Flitestar. By the way, do you know of a good video or tutorial for Flitestar / Flitemap. There are a large number of densely packed features in there!

Pete, the first flight plan I modeled was from Auburn, California (KAUN) to Lakeview, Oregon (KLKV). The plan I produced has placed the coordinates of KLKV at all values set to 0. When you load it into the FS2004 flight planner, the destination ends up being the ocean somewhere around South Africa. :) I will try to figure out a way to post a file here, otherwise I will send you the plan in Flitestar and FS2004 formats by e-mail.

I got it working, and thanks for your help. The key insight, which I didn't understand because I haven't used Flitestar very much, is that the Navigation Log is located on the Reports tab. I should have read your document more carefully. You may want to put the section you quoted in bold, if it isn't already. My Save and Save As work fine. What I meant was that I had hoped those actions would trigger your program. I do see the problem you have to deal with in capturing this data. Perhaps a command line utility to take a Flitestar file as input and create various outputs from that would be useful as well.

I'm sorry for not getting it, but in spite of reading the documentation I cannot get FStarRC to work with Flitestar 8.5. I load Flitestar by selecting the FstarRC EXE, but no matter what I do it never creates any additional files in my PATHS directories. What is most unclear to me is what explicit sequence is supposed to trigger creating those files? The documentation says printing the flight plan will save the files (which is quite weird, but okay I did it and no files are created). I also tried Save and Save As, and neither of those actions creates files either.

Excuse me, but how many times do we need to say that we are not using this device for navigation before it sinks in to this thread? You don't need FAA approval to bring in street maps to the cockpit, and surely pilots do use these to improve situational awareness. Just don't *rely* on that map to make navigation decisions. If I bring in a picture of a mountain range, I guess I could use that picture to improve situational awareness too. Looking at that helps to confirm decisions made based on approved devices or maps. To say that the FAA never wants us to confirm any decision we make on an FAA approved device or map is silly. The bottom line: You don't need FAA approval for the device I am describing. It isn't used for navigation. Regarding altitude: for the application I am describing vertical accuracy to 100 ft is fine, and GPS gives you better than that today. See this research article on GPS http://www.bluecoat.org/reports/Graham_2001_RawGPS.pdf It makes the claim that we are empirically already seeing on average better than 25 ft vertical accuracy with the current (non-WAAS) GPS systems. That is *on average*. You cannot *rely* on that level of accuracy today. You are not understanding my examples. I am not using this device to shave a 50 ft margin of accuracy when clearing a mountain ridge. I am using this device to realize that I am 500 ft below the mountain ridge and that I misread my FAA approved map. That causes me to then check and double check the FAA approved instruments, in the hope that I will find the source of my error. As a worst case, if I cannot resolve a discrepancy, is it going to hurt for me to ask the sector controller for another 2000 ft? Nothing on the FAA approved map or device contradicts doing that, and what is the harm for simultaneously navigating according to the FAA approved method and also confirming the decision in a non FAA approved method that improves situational awareness? The purpose of the device isn't to *make* navigation decisions. The purpose of the device is to help me confirm those decisions by showing me potential gross errors or miscalculations. GPS is about to take a huge step forward with WAAS, and the horizontal accuracy of that is around 10 ft. That's good enough to land the airplane which is why your beloved FAA is currently planning to allow WAAS GPS approaches to feed altitude to the autopilot to make auto-descent part of the approach. At the FAA's usual pace, that will take years to make happen, but the technology for it is here today. There is a good article on WAAS here: http://www.avweb.com/news/avionics/185185-1.html Lifted from a source online: "IFR GPS units like the Garmin GNS 430/530...are certified under TSO C-129 (Class A1 for en-route, terminal and approaches, or Class A2 for enroute and terminal), and are approved for supplemental navigation. New WAAS-capable receivers like the UPS CNX-80, certified under TSO C-146a, qualify as primary receivers and will fall under different rules." That's neither here nor there, because you don't need that level of accuracy for what I am describing. Regarding attitude, there are currently portable gyro and EFIS systems for under $1000. http://pcflightsystems.com is a good example. As long as you have an API, any portable gyro can be used to feed the attitude to FS2004.

Pete, I'm looking for some very low-cost way to tie in real world devices to act as controllers for actions in FS2004. I'm discouraged by the high prices that the various cockpit makers charge for their plastic avionics panels and various flip switch boxes, and I want to see if I can find some generic I/O boxes with turn gauges, and then tie those into FS2004. What support for this kind of thing is there in FSUIPC? Is there any way you could provide a non-programming interface to such things, or is there just no generic interface in Windows that lets an I/O device provide its name, the control's name, and the action that was provided with the control, in an abstract format that you could watch for and present for mapping to FS2004 controls?

Let me give an example of an improper use of FS2004 during an IFR flight, and then separately what I think would be a proper use. An improper use would be not pulling out an IFR chart at all, and seeing that you can "clear that ridge" in the FS2004 display that is following your flight. Such a use *relies* on the FS2004 simulated display to make navigation decisions. FS2004 of course has a margin of error, even with Justin's magnificent terrain added, important details like that 1000 ft tower straight ahead, don't show on FS2004 at all. A proper use would be doing a proper IFR flight plan using FAA approved methods and maps. On a particular IFR segment you look at the FS2004 display for situational awareness. Oh, you think, what's that huge mountain coming up straight ahead? You double-check your IFR chart, and then you realize that you didn't read it correctly. Or alternately, the IFR chart doesn't resolve the discrepancy. But, just for additional margin of safety, you ask ATC to let you go up 2000 ft. So a proper use is to act as a kind of double check against other instruments or maps. Properly used, it can only motivate decisions that will make you more safe, not less. On a very pragmatic level, a lot of pilots do run into terrain in IMC conditions, and many of those are IFR rated pilots. Many of these read their maps incorrectly, or get misoriented relative to some instrument. For example, they forget that they are doing a backcourse and instead hit approach. On a very fundamental level, having a clear 3D graphic display that shows you terrain ahead is at minimum going to make you check and cross-check your instruments, and common sense tells you that this is going to save lives.

No, I would never use FS2004 to *navigate*. That was stated clearly from the start. I would use FS2004 for situational awareness. There is a huge difference.

Peter, FS2004 is three dimensional. Most moving maps infer topography in a two dimensional view. One nice application for using FS2004 as a moving map is to give you sensitivity for the size, shape, and number of obstacles around you when you execute an IFR flight plan. IFR charts do not show you the topography around you, but simply guarantee that if you follow the IFR rules you live. It doesn't hurt to have something visual to back up the need to follow those rules and add some additional situational awareness. [/i]