dfournie

The unit just came last week. 1000 lb crate. Egad. I don't know about the firmware. From your description it acts like it may not be updated. Good question. I will find out. The electric trim sometimes seems to have a mind of it's own. After reading your reply I believe it is sending both trim axis commands and trim controls. It looks like it's getting into some sort of a feedback loop where the trim switch is controlling both the FS2004 trim and the electric trim until they get out of sync. Makes sense. This would probably explain why the trim moves on it's own sometimes. It's fighting to get itself back in line with the trim in FS2004. Way cool. I will try that. Didn't dawn on me before. FSUIPC is 3.50, PFC.DLL is 1.92.

Pete, I just received my PFC Modular Flight Deck w/electric trim. I'm trying to understand the operation of the electric trim mechanism and how the trim wheel and it's associated trim indication stays 'synched' with the trim position in FS2004. I'm starting to find some situations when the trim rate and position supplied to FS2004 does not appear to match the rate at which the electric trim motor trims the flight controls on the modular flight deck. After a while either 1) the trim inside FS2004 reaches it's maximum up/down limit, or 2) the electric trim on the MFD reaches it mechanical limits and then no longer matches the trim position inside FS2004. It appears to me that the trim switch on the yoke sends both a command to FS2004 to run the trim (as it would in a PFC yoke with no electric trim), but also sends the command to drive the electric trim motor in the flight deck. These two operations don't always seem to occur together at the same rate. I did notice a pitch trim reset that is available in the PFC.DLL user interface. It appears to reset the trim in FS2004, but has no effect on the MFD trim motor/wheel.

Don't touch a thing!!!! It works perfectly. Thank you VERY much for the assistance. I appreciate your work.

Thank you Pete. It works very well. The only thing I see wrong is the checksum being generated for the 2nd GSV sentence. It's supposed to be 74, but it seems to be coming out of MSFS as 73. The sentence is rejected by my map. I've checked it twice and keep getting 74 as the correct checksum. Here's the 2nd GSV sentence from latest gpsout.dll 2.581: $GPGSV,2,2,08,09,25,213,49,04,23,044,49,06,17,287,49,07,05,089,49*73 Here's the same 2nd sentence coming from a real GPS: $GPGSV,2,2,08,09,25,213,49,04,23,044,49,06,17,287,49,07,05,089,49*74 They are exactly the same except for the checksum at the end. You don't need to fix it if you don't want. I don't want to trouble you anymore. If you do want to fix it, that's fine too.

My bad, Pete. Please ignore the previous post with the newer GSA and GSV sentences. They were goofed up. Honest to goodness, this one is right. Sorry for the inconveinance. $GPGSA,M,3,10,06,04,09,02,07,30,05,,,,,1.6,0.9,1.3*3B $GPGSV,2,1,08,05,77,295,51,02,69,033,50,30,39,315,49,10,36,141,49*7B $GPGSV,2,2,08,09,25,213,49,04,23,044,49,06,17,287,49,07,05,089,49*74

Many thanks Pete. I tried the built in GSV with ver 2.57 and it really does work. Much like the GSA in 2.57 it contains just enough to make a mapping program accept it as valid. The three sample sentences I provided, that you included in build 2.581 also worked fairly well. Unfortunately the ones I provided, happen to have had poor satellite geometry in the sky. Sorry about that. These sentences below have 9 satellites and give a much better "view" of the satellites being used for the position calculation. Along with very good DOPs. $GPGSA,A,3,10,28,24,04,09,02,07,30,05,,,,1.4,0.9,1.1*31 $GPGSV,3,1,09,02,73,184,50,04,53,052,50,09,50,245,50,05,45,318,52*7F $GPGSV,3,2,09,07,24,065,49,24,12,040,49,30,10,311,49,10,08,162,49*7F $GPGSV,3,3,09,28,02,123,49*45

These would work fine: $GPGSA,A,3,07,08,11,13,28,29,,,,,,,2.0,2.0,2.0*3F $GPGSV,2,1,06,07,31,214,44,08,82,021,51,11,31,102,44,13,08,176,36*75 $GPGSV,2,2,06,28,61,304,49,29,28,305,44,,,,,,,,*7F Explanation: Your current GSA sentence is technically correct, but is not representative of a real world GSA sentence. It appears there is just enough info in your GSA sentence to get most mapping programs to accept it. The one above basically says you have a 3D fix, with DOP's of 2.0, and have 6 sats available. The smaller the DOP numbers, the better quality of the fix. I would like lower DOP's than the current GSA sentence allows (All 3.0), and having 6 sats is much more realistic for a true 3D fix. The two GSV sentences above refer to the individual satellites in view (listed in the GSA sentence); giving each's azimuth, elevation, and signal to noise ratio. There can be as many as 3 GSV sentences in a row depending on the number of Sats the GPS "sees". The six satellites from the GSA sentence fit in the 2 provided. These would normally change as sats move around and drop in/out of view. The static one's above would be just fine. Two of my mapping programs require both GSA and the appropriate GSV sentence(s). I would assume the checksum would be generated by your code and tacked on the end of each sentence. Possibly have the ability to choose to have the GSV sentences in the output as are currently the chices for RMC, RMA, GGA, etc...

Pete, I have two requests. 1) Would it be possible for the GSA sentence output from GPSout to get additional info added to it? Right now it has just enough of the fields filled to get a mapping program to recognize it and make use of it. According to the NMEA spec it has the active satellites available along with fix type (2D/3D), and accuracy info. The info I would like it to output does not need to be updated dynamically ie. the same GSA sentence can be sent out again and again as it is now with all the fields filled. 2) Along those same lines, could a choice be added for GSV sentences? Normally this sentence lists the satellites, their azimuth, elevation, signal to noise ratio, etc... Once again this data would be static and just sent as the others are. I can give you the complete sentences with the appropriate fields and checksums, if you deem this request worthy.

Try this link: http://www.hwgroup.cz/products/hw_vsp/index_en.html It's completely free. It's made to work with this company's equipment, but they state it may work stand alone too. Unzip the program to both computers, set one up as the server and the other as the client, using each others IP addresses. Works very well. The file name is; HW_VirtualSerialPort.zip The linked page has very detailed info on how to get it working. Pete, the ToshibaBT Ports are virtual COM ports for use with Blue Tooth. I had to turn off Blue Tooth and remove all associated software to get rid of them. On my tablet PC those ports were actually interfering with the USB to Serial converter I installed to act as COM1. I'm not quite sure why, but one I removed them it started behaving. Dave

Pete, On a related subject, I just received my new PFC airliner rudder pedals and noticed they are USB, and are detected by Windows as a normal joystick. It is unclear to me how they interact with the PFC.DLL driver I have loaded for my original cirrus yoke, and throttle running though the serial port. They work quite fine, but (as to be expected) are not detected in the PFC dialog pages. Is PFC leaning toward all USB connections? What would happen to the PFC driver you've authored? Would it even be necessary?

My flight director sends a constant stream of roll and pitch commands at 20 times/second which I am parseing down to 10 times/second and passing on to the feedback facility. I have my flight director successfully driving the feedback facility to fly precision approaches down to touchdown, hence my need for updating probably more than what the feedback facility can handle. It does work quite well at 10 times/second. I've just had to mess with the fiddle factor numbers to get the precision I need. I will try something along the lines of 1 update per second, to see what response I acheive. Would there be a way that instead of the feedback facility being given a target pitch/roll that it would accept a constant streaming pitch/roll input instead and let my external flight director perform all the calculations to acheive the target pitch/roll?

I am changing the value at a rate of 10 times per second. I never thought of slowing down the update. What would you recommend as a suitable update rate?

Pete, Before I forget to ask; would you expect there be any noticeable performance difference between using the autopilot feedback facility over a network; ie with normal wideclient/wideserver, or by using it directly on the same computer Flight Sim is running on. In running some tests it seems that the feedback facility does not like running over a 100Mbps network as it appears there is too much of a lag and the roll/pitch axis rock back and forth wildly. In running the same code on the same computer that Flight Sim is resident, the oscillations seem to disappear.

You have a valid series of points. The roll and pitch feedbck portions work great. The feedback control facility correctly coordinates the turns with the info it is receiving. I guess all I was asking was that an option be added to stop the feedback facility from performing the calculations necessary to determine rudder input/yaw damp and let that information be supplied from an external source. Now that I better understanding of how you are generating the rudder inputs to null out adverse yaw, it really is not necessary to change the feedback control facility.

Pete, Would it be possible to add a 'yaw' control to the feedback control facility? I have the capability to send a third channel (yaw) from my external autopilot, but nothing in the feedback control facility to send it to.

Pete, If higher resolution 3rd party terrain mesh data is installed in place of the default FS2004 terrain data, will FSUIPC calculations (Rad Alt, etc) that use this higher quality data be any more precise? Or are the resulting elevation calculations still based on the original lower quality (and higher spaced apart) Microsoft terrain mesh data?

Pete, I'm currently using the world frame axes offsets to successfully determine all my positional information, velocities, and accelerations. When I am at a steady state, no accel/decel, no wind, on the ground, the world frame axes show no relative movement as would be expected. However the body frame reference variables from their associated offsets appear to be sensing positional movements and accelerations. The values appear to be very small, but are there nonethless. Is the body frame reference actually seeing engine vibration from the aircraft standing still? I would think these extremely small velocities would be present in a very high resolution flight model, but not in FS2004.

Pete, In memory offset 02B8 you are providing True Air Speed, which in real aircraft is a derived value generated in the Air Data Computer. Are you performing the temperature and pressure calculations using Indicated Air Speed as the input, and outputting the result of the calculation as TAS in this offset - or - is the TAS value in this offset coming directly from Flight Sim with Microsoft having made the IAS to TAS calculation for you?

Welcome back Pete. I've since successfully got it to work. There seemed to be a sign problem (+/-) - I think I had them reversed. The only things I'm having trouble with now are the fine tuning of the roll and pitch when the target value has been reached - while the autopilot is attempting to maintain a straight and level state, and trying to get FS2004 to match my external flight director for commanding it's roll/pitch. Even with higher numbers plugged in for max rate of degree change and maximum total degree pitch/roll, I sometimes have a slight delay in FS2004 in trying to keep up with the roll and pitch commands it is getting. I know there is some limit with the roll/pitch authority provided by the King Air flight model I'm using. There is a considerable amount of wing rock and in certain situations some dutch rolling tendencies. Can you shed some light on the "fiddle factor' values? Are these just for ultra-fine tuning for the autopilot "gains" I'm using to preciesly control the FS2004 flight model? I'm fairly sure I've got the macro and micro values for pitch/roll control pretty much dead on.

Has anyone had any luck using this feature? I've been experimenting with it by sending the correct strings of data to the pitch and roll (0700 - 0717, and 0718 - 072F) offsets and it doesn't appear that FS is reacting to the external control inputs at all.

Just use the localizer and glideslope deviations from FS2004 to drive the real instruments. We tune Nav1 inside FS2004 using the Universal RTU and then just send the respective localizer and glideslope information over CSDB to the displays. I can't recall off the top pf my head what we used for scaling, but it works quite well.

It's for a US Air Force King Air. It's a flight training device.

I'm using FS2004 to drive a GPS satellite simulator. The GPS sim is a UNIX based VXI/VME chassis that accepts an external input from FS2004 and outputs an RF signal to dual UNS-1F NCUs. The whole system also includes 3 EFI-890R displays, and dual RTUs. Works quite good. I've also experimented with sending the 429 GPS positional signal info directly into the UNS CDU as well. It just fakes out the internal NCU GPS and gives it a constant 8 sats with all DOPs of zero.

I did actually see a better filtering in the flight controls page. The reason I say this is because of a 'dead spot' in the pitch axis potentiometer of the PFC yoke. It was a separate problem I had been seeing. It was getting rather annoying. I ran a Volt/Ohm Meter across the output pins of the yokes DB-15 connector to verify I wasn't going mad. The dead spot appears to be handled much better (ignored) now for some reason. It works good now so I'm not going to touch it.

Pete, It made a fairly significant difference. Using the test pfc.dll and a different USB to Serial converter, the controls seem to be more responsive and appear to have a better digital filtering algorithm. The display stuttering is also gone. I turned off all Power Mgmt in BIOS.