dfournie

Thanks Pete, I'll try it. I have the PFC Beech Yoke, TurboProp power quadrant into the digital I/O Box that connects to the serial port. I've tried it with both a built-in Serial port and a USB to Serial connector. I've seen it happen with both. I'll double check to make sure Power mgmt is off.

I'm troubleshooting a flight control problem I've seen develop over the last two weeks in my setup. Occaisonally, I experience FS2004 not accepting any inputs from my PFC flight controls. Whatever manuever I'm in (climb, turn, etc) continues without letting me intervene. FS keeps flying OK, but ignores flight control input. After a few seconds FS2004 pauses for just a moment, then allows normal flight control input. I haven't installed anything new. Before I blow away the whole installation and start again, I was wondering if anything like this has been seen?

You are 100% correct. This may shed some light on what I'm doing: I have FS 2004 interfaced into an actual Rockwell Collins Pro Line 21 system. It is a cockpit upgrade for an analog system we are tearing out. It will be making its way into a US Navy King Air at some point. Our sim lab uses a GPS satellite constellation simulator that models the GPS system and sends output as an RF signal to drive a real world GPS. We have the positional output from FS2004 "driving" the simulation around. I was trying to narrow down the cause of the error I am seeing in altitudes in various places. I now believe it is due to WGS84 GPS altitude as it is provided by my GPS simulator. The worldwide altitude data I'm using just doesn't match the FS2004 world exactly. As to be expected. I'm just doing some stuff that is slightly past the homebuilt sim stage.

The explanation is clear. However, the GPS datum used for Flight Sim 2004 (WGS84) uses a mathmateically derived altitude reference. GPS altitude measures the users' distance from the center of the satellites in orbit. These measurements are referenced to geodetic altitude or ellipsoidal altitude in some GPS equipment. Garmin and most equipment manufacturers utilize a mathematical model in the GPS software which roughly approximates the geodetic model of the earth and reference altitude to this model. As with any model, there will be errors as the earth is not a simple mathematical shape to represent. What this means is that if you are walking on the seashore, and see your altitude as -15 meters, you should not be concerned. In my setup this is very relevant. It's just an accuracy thing. Sorry for the GPS lesson, but it looks like I need to change the code on my end. Thanks for the info.

I see that the offset 31E4 supplies a derived (aircraft altitude minus ground elevation) radio altitude for the aircraft. Does this number take into account changes in pressure and temp from 29.92 and 59F? Or, another way, where does the value "aircraft altitude" come from in the 31E4 derivation? Is it just an "aircraft above ground" value, or does this "aircraft above ground" value vary with pressure and temp? In a real aircraft this is obviously a radio transmission/reception by the antenna on the bottom of the aircraft. Not affected by pressure. I'm just trying to get some insight on how you are calculating it.

I'm using a PFC Beech Yoke/Throttle with FS2004. Is there any way to increase the speed that the electric trim switch drives the trim inside FS2004 - other than a max value in the PFC.DLL Yoke button assignment page. I've already tried that and would like it faster still. It appears the trim wheel in FS2004 runs slowly when trim up/down is initially pressed and speeds up as the trim switch is held. I guess I'm looking the trim speed to be a steady fast(er) value.

A high-level general description of the NMEA 2000 initiative can be found at: http://www.lowrance.com/Manuals/Files/N031804.pdf

Good question. Without having the actual spec in front of me I would suspect the NMEA data is obviously not treated the same as it is in the v-0183 serial spec. Because the shipboard equipment that is receiving the data are stand-alone units (not PCs) with a direct Ethernet connection, I would guess it would be some sort of packet-type transmission. The reception protocol would most definately be covered in the 2000 spec as well. If you want the 2000 spec Pete, say the word. I will attempt to get it for you. There are freeware and payware programs available on-line that redirect a com port to an ethernet port and vice-versa.

The most recent NMEA spec (NMEA 2000) adds the capability to distribute NMEA positional information over a shipboard ethernet system. I would suppose to various autopilot/mapping/sounding equipment around the boat.

The original NMEA specification is ONLY for a serial connection at 4800bps. My Sony PDA is USB, but I was able to find an adapter to go from the Sony proprietary connector to a DB9 male serial. I just threw a null modem connector in line and it worked. I believe there is a newer NMEA 2000 specification on the horizon that essentially puts an ethernet network on the ship/vehicle and sends the NMEA data zipping around at 10 Mbits.

I've tried GPSOUT.DLL into about 10 GPS different receivers that have NMEA input capability. All have worked perfectly, as it appears Pete is strictly adhering to the NMEA spec for the produced sentences. Unfortunately for the normal user, of these 10, only 2 are consumer level systems - 1 aviation and 1 marine. The other 8 are military.

RTCM is the Radio Technical Commission for Maritime Services. They more-or-less set the standards for shipborne GPS precision receivers. Using a radio frequency based diferential GPS ground station with a known location, a GPS unit set up in RTCM IN/OUT mode, can tune to this ground station frequency for precise correction of the GPS induced wandering that is introduced into the GPS satellite system. Mostly used in ship harbors by harbor pilots for precision navigation in tight areas. At work I use a GPS constellation simulator. It is a UNIX based system with hardware/software that correctly models the entire GPS satellite system for a given location/time. It outputs an RF signal that can be connected to any GPS antenna-in port. Using conrol software we can "drive" the simulator around and simulate movement. In comparing Pete's GPSOUT.DLL from flight sim to the same data coming from the simulator we see virtually no difference in location and tracking. Unless Microsoft plans on making the GPSOUT feature part of their next Flt Sim 200X release, you can't beat what Pete has done.

I agree, there seems to be no track error problem now. The only reason I even brought up the Magvar issue with FS2002 is because I am hardware limited on the laptop I am runnng it on. The machine doesn't quite have enough power to run FS2004, yet is more than capable of running FS2002. Using the magdec.bgl from FS2004 wouldn't be possible would it?

Thanks for the fixes Peter. I think I've stumbled across another one that is nothing you can fix, just an FYI. The FS2002 Magvar tables are obviously 2+ years old. By using just about any moving map with the most current Jepp/NIMA/etc navdata and FS2002, there is a slight difference between the 2002 magvar and 2004 magvar values (as would be expected in some locations). I have noticed 1 - 2 degree differences around the US in Flight Sim 2002. I would suspect FS2004 does not have this problem being it has a newer magvar table to consult.

Thanks for the info. The cool thing about these demos - - they accept NMEA input through the PC serial port. I've tried on the Aviation 1000 unit, and one of the Marine units using the NMEA output from my Garmin III. I suspect they transmit the simulated NMEA out as well. I have to try that next.

Interestingly enough, I tried GPSout.dll running in AV400 format into a real Honeywell MFD-640 moving map/TCAS/Terrain awareness display and, after some re-config, it liked it. Normally this $30,000 unit runs with ARINC 429 as an input, but it appears to accept this as well on another set of input pins. Also, the Apollo Precedus (combo handheld gps/nav/com radio) seems to use this format (AV400) as it's default output. I was also able to drive a couple of other moving map programs with GPSout by selecting the Apollo format as the input. I recall this format is also used in some ARGUS moving map displays.

I just would like the option to see/not see the message box "Same program or class already running (FS98MAIN)". All the rest can function normally.

Pete, This may be way down in the weeds, but would it be possible to request a switch (Yes/No) in the Wideclient.ini file that determines whether to show the message box that is displayed when it is attempted to run a second copy of WideClient with one already running? ie a "silent" mode. Thanks.

It has a NMEA input mode. It more or less just acts a display and decodes incoming NMEA sentences. I assume for another ships GPS unit to send steering commands or other data into it. It has about 10 different transmit/receive modes; (NMEA 1.8, 2.0, charting, ASCII text out, NMEA input, etc...) I also tried it connected to my real Garmin GPS III in NMEA out mode, with the same results.

I actually tried GPSOut into a marine (shipboard) GPS. It is an older model (heavy as a brick), but it works nicely. No graphical display, only text, but right on the money with a decent update rate.

When an aircraft system, or specific instrument is failed using the Instructor Station in FS2002, does FSUIPC reflect this? ie. If Heading Indicator is failed, is the correct heading value still supplied to it's associated FSUIPC memory offset, or does it contain the frozen Heading value at the time the faliure occured? Same with attitude, airspeed, etc...

Memory offset 0898 and 08C8 deal with Eng #1 N1% and prop RPM. Memory offset 2000 also appears to contain N1% for Eng #1. 1) How does the value in 08C8 relate in the conversion required from N1 to prop RPM? What is actually in 08C8? N1 values are usually in the 30,000s, prop RPMs for a King Air are around 1700-2000 RPM. 2) Why is they also another offset at 2000 for Engine 1 N1%? 3) When 0898 is converted properly with 08C8 will it equal the value in 2000? In the case of a turboprop, is the recip engine prop RPM offset also used for turboprop RPM?

I actually have a military flight planning program w/moving map called Falconview. I'm registered as a developer and the SDK it came with has source code samples that allow -ANY- input source the user has to drive the moving map. It works great with GPSOut. My C coding is abysmal so I can't use any of the SDK to send FSUIPC info directly into the program either over the network or on the same computer. I suspect for a good coder this would take about 5 miuntes to do. I have all the documentation, type libraries, etc. for it. If someone wants to take a look at it they are welcome.

Pete, Is there a memory offset location in FSUIPC that would allow a programmer to read yoke button/rocker switch presses (events) on a PFC Cirrus Beech yoke? For example: a press of the right rear-mounted button on the Beech yoke would set off an external event (or run a program), etc.

Is the source code available for FS Traffic Look and FSlook/FSlook2? It would be a nice bit of code reference.