Pete Dowson

Rightso that's presumably where I got the AV400 format from? This will be the document I can't find at present. But this was about two years ago -- the files (and emails) will be long deleted, maybe archived (I get about 2000 emails per week so I cannot keep them all on-line!). Regards Pete

Yes, of course. You calibrate the two throttles on page three of the Joysticks tab ("Separate throttles per engine"), and check the option which says "Map 1->12, 2->34" You can also fly a three engined aircraft by an option to map 1->12, 2->3 (for symmetry only the centre engine is then separated). >> Of course I realize that operating single engines would not be possible then (only seeing two engines as one). << Yes, it will be -- just use the throttle assigned to engine 1. This is actually covered, albeit perhaps a little briefly, in the FSUIPC user documentation. It's in the Joysticks section, in paragraphs starting with "There are four special cases you may want to deal with". Take a look. Regards, Pete

Test it on a default aircraft. If it is something peculiar to the Dreamfleet 727 then you really need to ask them. All the reverser is doing in FSUIPC is sending appropriate negative thrust values to all engine throttles. The usual problem is that the normal throttle(s) is/are not quite in idle, but that stops you going into reverse, it doesn't stop you coming out. Does the 727 go into reverse using the F2 key to keep decrementing thrust? If you do this till it gets to maximum reverse, does it come back out gradually on pressing F3? Regards, Pete

Use the electric trim on the yoke, as real pilots do. Never use the trims on the console except for initial setting up: they are "trim pots" not aircraft trim wheels. My test rig is still using a Jetliner console, but there really is no more development I can do for it. Everything works as needed, and you can re-program pretty much anything you want through FSUIPC. Regards, Pete

No, not at all. That, as I said in my last reply, is Garmin's protocol for transferring routes, fixes, track logs and so on. It is nothing whatsoever to do with making the GPS into a mere moving map for another GPS position source. Did Tuomas send me something? I am at a loss to know what you are talking about I'm afraid. Can you give me a reference? I implemented the AV400 facility in GPSout years ago. I cannot even find the original specification now. But check in the "Interface Settings" section of your Garmin manual. You'll see some definitions, like: * Aviation In -- allows the unit to commiunicate with a Garmin panel-mounted GPS ... * Garmin -- the proprietary format used to exchange waypoint, route, track log data ... * NMEA -- supports the input/output of standard NMEA 0183 data ... Of these GPSout supports the first and third. The second has absolutely no provision for driving the GPS unit as a moving map! Regards, Pete

FSUIPC doesn't use its own terms. All the FS controls use the formal names Microsoft defined for them, as defined in its "CONTROLS.DLL" (which is where FSUIPC reads them from), and listed in the List of FS2004 Controls which is included in the FSUIPC ZIP for your convenience. The "CRS" value is known as the "OBI" (probably for Omnidirectional Bearing Indicator, but I'm not sure). There are these FS controls: Vor1 obi dec Vor1 obi inc Vor2 obi dec Vor2 obi inc The NAV1 radio is linked to the left CRS, OBI1, and the NAV2 radio to the right CRS, OBI2. I think the term OBI is used on light aircraft, CRS (course) on airliners. Regards, Pete

I've seen all that stuff before. It's for transferring tracks, waypoints, routes and stuff like that. I don't think you will find anything in there about GPS data input, which is what you are wanting. Fixes (i.e. waypoints) are to do with plans you download to your GPS so it can follow them. All that stuff is to do with using your GPS for the purpose it was designed -- i.e. a GPS. With FS and GPSout you are only wanting to use it as a moving map, not a GPS at all. I prefer using a PC for that as the screen is bigger and clearer and there is a wider choice of maps. but some folks do want to use the GPS instead. However, this uses that GPS in "simulation" mode, wher its own GPS hardware is switched off and all you are really using is its display. Regards, Pete

No idea, sorry. But your cable must be fine if you get some good data. Pete

I just checked -- the 4 or 6 decimal place option doesn't apply to the AV400 format in any case. That's fixed as defined in the AV400 spec (more below). But most all of the output must be right as you said "Track is good ,speed is good,alt is good". I can't see how the device can get those correct yet screw up the latitude and longitude. It doesn't make sense. If you had anything wrong with the connection data none of the values would be correct. Well, the actual protocol I implemented is called "Series 400 Aviation Format", so maybe there are other "Series XXX" versions. Isn't anything mentioned in your GPS documentation? If you can get details of whatever protocol is used, and it isn't too far removed from what I do already, I can consider adding it to GPSout. Maybe you can get stuff from Garmin? Regards, Pete

Where are you looking at the Needle values? You cannot necessarily judge it by the on-screen monitor display facility as I think that will be affected by the FS display logic (though if you are using the same for the altitude I suppose that's discounted already). FSUIPC's Monitor operates up to 4 times the frame rate, so maybe logging to the Log file will work. FSInterrogate's update rate isn't all that fast, but faster than 500 mSecs by default I think. However, if any of the methods "look" like as much as half a second then it seems that it must be pretty sssslllloooowwww. I could send a test version of FSUIPC which updates those locations as much as 4 times the frame rate (varies) but I don't know how you'd monitor it fast enough to check, and it would be an even bigger waste of time if indeed FS is limiting them somehow. If FS is limiting the update for these values it is probably a performance thing, based on the assumption that the only thing which needs them is the gauge and its resolution wouldn't support a faster rate in any case. What exactly are you needing this for in any case, BTW? Are you trying to control landings using the GS/LOC? Wouldn't simply maintaining the correct V/S and Heading, once engaged, be better if so? The values for these (GS angle, correct and accurate heading) are available. Regards Pete

If the FS2004 install is on the same PC (without a Windows re-install), then you only need to copy the FSUIPC.KEY file into the Modules folder. Otherwise you need to re-register -- but you MUST use exactly the same details as before. The software does NOT change like that, and purchased keys have no expiry date. But the Key is intricately related to your registered name and email. Every single character of every part of those three things must be correct. If they are it will work, if not it will fail. In almost 100% of cases the problem has been that folks use different names for themselves at different times, or change email addresses. The KEY only works with the ones you registered. (The only exceptions were some names with accented characters in the very first release two years ago, quickly corrected, and keys which have since been blocked through use of illegal generators, lack of payment, or breaking of license rules such as openly publishing details or sharing them with others). If you believe you have entered everything correctly and still have problems, please put together all the details, including if possible the original notifying email you received with the Key, ZIP them up and send them to me at petedowson@btconnect.com. Do NOT publish any details here. Regards, Pete

I have no idea what FS's update rate for these things are. I said that I'd changed FSUIPC's priority, for those only, to make them update on every frame. In other words I read the values and place them in those offsets on every frame. Whether FS changes them on every frame I've no idea. Possibly, or equally possible, the resolution is still quite limited so you don't see small enough changes. If they definitely are only changing every 500 mSecs then I can put them on my lowest priority -- a 440 mSec update rate I think -- along with the FS98 equivalents at 0C48 etc (I think those are on a 110 or 165 mSec rate at present. Apart from my frame-related rates, others are all multiples of timer ticks which, at 18.2 Hz, are 55 mSecs apart). I don't like to waste time unnecessarily! ;-) Regards, Pete

Try setting the PosTo6Decimal to "No". Maybe the excess digits are mucking it up. I really can't think of anything else it might be. Certainly nothing in your FS scenery add-ons. Regards, Pete

Well I know that the 737NG configuration for pmSystems is good -- I use it. Actually I use one developed from the default by Thomas Richter. You can find it attached to some of his messages in the PM webboard/newsgroup. Certainly the Cutout operates okay, for example. To check things with pmSystems you need to view the switches on the graphic whilst operating your own hardware switches. Well, pmSystems is very flexible but it does take some work. Your best bet to get help is to post on the PM webboard rather than here. There's a dedicated pmSystems section with some very knowledgeable and capable folks in attendance, like Andras Kozma and Thomas Richter. Regards, Pete

The 56xx range of offsets is used by pmSystems. Do you use/own pmSystems? If not then you need to use the FS switches for these, as listed in FSUIPC's offsets. In FS "CutOff" is actually dealt with by the mixture control (full rich = start, full lean = cutoff). For any FSUIPC offsets operated by your hardware you can Monitor them in FSUIPC's Monitor facilities, as documented. See the Logging tab in the Options screen, right-hand-side. This is a good way to check that your hardware is doing the right thing. After that, if it doesn't do what you expect you have to investigate the target software, in the 56xx case this being pmSystems. You'll find documentation for both FSUIPC FS offsets and the standard PM offsets on the http://www.promagenta.com Documentation page. But for pmSystems (which is entirely user configurable, INCLUDING the offsets) you'd need to look into the SYSVAR.TXT file supplied with the package. Regards Pete

Oh, right. I'd never have guessed it would be a DX problem. Nothing of mine uses DX so it's an area I'm rather ignorant of I'm afraid. Glad you got it sorted. Regards, Pete

What is? Sorry you've lost me now. I've no idea. Sorry. This sort of question is best put to the PM support folks, surely? Well, they've adjusted exactly enough on both my old B&W 5" monitor with the PFC CDU panel, and the twin colour 5" TFT ones built into the PFC cockpit. I think both the OpenGL and the GDI displays are fully adjustable in all sorts of ways. The methods aren't intuitive unfortunately, and don't ask me to explain them. But they do the job. I'm sure PM support will be able to help you. Regards Pete

Sorry, I don't understand. What is "trc# 1047"? What are you really meaning by "PM codes" as opposed to "FSUIPC codes". I'm afraid you've lost me completely. Pete

Not that I know of. Sorry. Pete

I'm not the person to ask as I don't like the OpenGL CDU display, even though it is more "realistic". I feel sorry for real Boeing users having to put up with it. I like the original PM CDU default "truetype" display, or whatever it was. I'm sure Boeing would too if they could get it! ;-) Regards, Pete

That's great! Well done! I shall make a note of that and maybe program some here too (but not WX mode -- see below). Thanks! I think there's some provision, deep in the PM CDU someplace. But I think it works differently -- doesn't the CDU program have to be run on the same PC as SA_WXR for that? I never got it working, but I don't run SA_WXR in either the PFD or CDU PCs. I switch the WX display on the ND using the WXR switch on the EFIS. i.e. from the PM side of things. I think the WX file stays in the ND folder whatever. The WX on/off for SA_WXR only controls its own display I think, except that obviously you need it ON to switch it ON or OFF in PM. Sorry, I don't. A question for the PM webboard perhaps? Regards, Pete

In at least the first two cases that is most certainly true. SB3 is complaining about the Multiplayer connection, which is outside of WideFS/FSUIPC altogether. ASV is merely asking for the full path to your FS installation so that it can manipulate the cloud graphics, something added in ASV from previous releases. it will be something like \\\... You probably need to make it a specific shared folder on the FS PC, and maybe even a mapped drive on the ASV PC. I'm pretty sure the ASV documentation goes into all this -- if not check with their support forum. As for FlightKeeper, I don't know, but I suspect it needs to scan all your scenery files in order to build a correct matching database. It may have to be run initially on the FS PC, at least for speed in doing this, then have the database copied over. I know I had to do this with TrafficBoard. The connection through WideFS looks okay from your logs, though short-lived because none of the programs actually ran for long because of the other connection issues. Yes, but do check the documentation for those programs more thoroughly first. I think these issues are normally covered in some detail. Regards, Pete

Thanks Nico. That's useful. It's a pity the same cannot be done with the PMDG series of aircraft. What about the PSS ones? Are they open to cockpit developments do you know? Regards, Pete

FSUIPC provides an interface to Flight Simulator. If Flight Simulator provides the facilities you are after, then you should certainly be able to access them in FSUIPC. However, FS itself does not support any special means of starting engines on any specific aircraft and, in fact, it doesn't even come with an Airbus model built in. For FS engine starting please refer to offsets 0892, 092A, 09C2 and 0A5A. Once you have turned on the power (battery), FS engine starting for jets consists of turning a starter switch, and holding it, and introducing fuel (via the same control as the "mixture" on props) at the appropriate time. Specific add-on aircraft may have more sophisticated, more accurate, ways of doing it, and these facilities may or may not overlap with the inbuilt FS facilities. Whether or not you can operate them through FSUIPC then depends entirely upon how the authors have implemented them. If you are using Project Magenta then quite sophisticated subsystems can be correctly implemented through pmSystems, and all of Project Magenta is programmable via FSUIPC and documented fully for this purpose. Regards, Pete

WideFS is quite unconnected to Multiplayer. I really don't know anything at all about multiplayer -- you need SB support on that. SB3 uses FSUIPC/WideFS for getting the aircraft position and setting stuff like weather. It uses Multiplayer to provide the images of other flyer's aircraft. Again this is nothing to do with WideFS, which doesn't connect folders. I think you need to tell ASV where FS is so it can manipulate the cloud textures. This is to do with the Cloud facilities now added to this weather program. I think the documentation covers it well. And what does it say? Possibly it needs access to the FS scenery files in order to build its database. Nothing you've said or shown indicates anything wrong with the WideFS connection, quite the contrary in fact. All the programs you refer to need other channels to FS's files as well as the FSUIPC/WideFS interface. I think you need to study their documentation a little more, please. Regards, Pete