Pete Dowson

There is only one version. I don't know if PFC supply one on disk or simply advise you to get it from their website. Either way you'll usually find the one on the Schiratti site to be more up to date. The current version is 3.40. Updates to the PFC.DLL will also normally appear quicker on that site. Regards, Pete

If FS2004 causes WinXP to crash and re-booot, it is something to do with a driver somewhere. no ordinary software can do that. It is probably either the video driver or the sound driver that is crashing. Sorry, i'm not an Airbus pilot. What does "+" "+" to flex mean? I don't know -- is there some sound that would occur then? Perhaps you should ask PSS support? Okay, so it loads a default flight not one you saved? Then you create a new flight rather than load an existing one? Regards, Pete

I now have all the PSS aircraft and I cannot make any of them fail. I really don't think it can be anything to do with FSUIPC -- changing versions merely changes memory arrangements a little. It does sound like there's something wrong in your FS installation somewhere. One common case of odd crashes is corrputed WX files, loaded with your Flights. The other possibility is sound -- wouldn't the cockpit voicing start saying something then? Maybe there's a bad sound file or problem with the sound driver. Try, temporarily at least, removing your FS9.CFG file so that FS makes a new one and boots with defaults. Then create an entirely new flight with the aircraft and try that. Wait a mo', are you flying FS2002, not FS2004? This is with an FS2004 version of the aircraft? What's WXP? Regards, Pete

But surely it depends on the weatherdifferent surface visibilities, cloud cover, etc? That's why I suggested using your FLT + WX files, to make sure I am looking at the same thing. There are too many variables otherwise. I just looked at the FSUIPC.INI file paramters you are using. These are the Visibility settings: You have something wrong there, which will probably make things not work right in any case. Your "Minimum Visibility" is set to 80 miles (8000), which is actually more than all your upper limits!!! Why tell FSUIPC to never let your visibility get below 80 miles? Strange. The default is 0, allowing thick fog when the weather says there should be. Without checking the code in FSUIPC, I'm not sure what this odd setting will do in practice, but it is certainly quite likely to ruin any attempts by FSUIPC to give you what you want! I'd also recommend setting the lower graduation altitude to 0 (in the Visibility Options) so that there's no gap between FS's visibility layer and the start of graduation. This is mentioned in the documentation. 33,000 feet is above the graduated visibility range in any case. Did you really mean that? From 20,000 feet, using an nVidia card, I get no flickering horizon, and in fact I only get a sharp horizon if the visibility value allows that. (There aren't any mountains in the UK which give a markedly bumpy horizon from high altitude in any case -- this is partly why I think the specifdic scenery is important if you want to compare things). As visibility is reduced, the horizon "fuzzes" -- the surface is still dark compared to the sky, of course. It looks quite good. I do have a Radeon 9800 in another PC, but it isn't switched on at present, it's in another room. I can try it later, but first please sort out your FSUIPC visibility options and see what you get. I still maintain that using the same FLT+WX files is still the only proper way to compare things. Regards, Pete

I've not seen any differences like that. Is this anywhere or just in certain locations? With default scenery? What is your weather source. If you can reproduce it with default FS scenery (and aircraft), save two Flights, at the two times with the same view, then Zip up the pair of FLT + WX files and send them to me at petedowson@btconnect.com. I will see if they look wrong on my systems, so we can perhaps deduce whether it is a video effect or something else. Mot sure what you mean by that. do you mean there is some "mist" but it is somehow flickering, or is it some part of the scenery sometimes re-drawing? The latter is often due to video card or driver problems I think. Regards, Pete

That's fine, as long as you understand that it isn't supported any more. No, because registration wasn't introduced into FSUIPC until version 3.00. Maybe the gauge is written only for FSUIPC 3 or later? I really don't know, you'll have to ask the author. No, that cannot be. The gauge's attempts to register will do no harm in versions of FSUIPC before 3.00, they'll simply be ignored. The gauge won't know or care either way. Regards, Pete

I didn't say the 96 couldn't. I don't know anything about it. All I said was that just because it provides NMEA 0183 support for output to a PC (as they all do I think) doesn't mean it accepts it as input from a PC. I'm not sure, but I think the other two you mention don't even use NMEA 0183 format for input in any case? Aren't they the ones with "Aviation 400" protocol supported, which I added to GPSout specifically? Please see, for example, this thread: http://forums.simflight.com/viewtopic.php?t=16610 Really, you need to refer to the documentation you should have got with your GPS. If it is possible for it to be set into a "slave" or "simulation" mode, bypassing its own receivers, then it should tell you somewhere in the manual how to do it and what protocol it uses. I'm afraid I only know about the units I have, neither of which will do this at all. Regards, Pete

No. It means little. Almost all GPS's, and certainly all Garmin ones I know of, support NMEA 0183 for output, in the same way as my GPSout does. Don't forget that the whole principle of the GPSout module is to make the entire PC + FS + GPSout system look like a GPS which is outputting standard NMEA 0183 data, for input into something else which understands it, as an input. It is quite unlikely that any ordinary GPS will act as a slave moving map or something like that for another GPS. I have two Garmin GPS devices, both outputting similar NMEA 0183 sentences to those provided by GPSout. Neither accept NMEA 0183 positioning from outside. They have their own aerials and position detection systems, and the only input they accept which can override that is some external aerial/beacon input which is certainly not NMEA 0183 at all. Regards, Pete

Currently it's nearest first. I can make 'moving' a higher priority selection criteria -- actually a moving 'state' rather than actual GS -- eg. taxi or takeoff/landing states. Then those with flight plan clearance maybe. Sorry, I'm not sure what this question means. There's been an Airborne table of up to 96 aircraft and a separate Ground table of up to 96 for a long time now. TrafficLook can select either -- see its menu. Sorry, I don't understand what question you are asking here. The information and control exercised by RCV4 is as documented in the FSUIPC SDK. All I'm considering here is a different way of selecting which 96 ground-based AI aircraft are listed (and therefore subject to all that RCV4 does). Regards, Pete

See these points in the recent release notice for 3.30: Those are the only accesses FSUIPC provides other than the regular weather interfaces. The relevant X and Z components are calculated for you by FSUIPC. In order to implement even these it has to intercept certain procedure calls between SIM1 and WEATHER.DLL. You know the term 'wind'. Ambient just means, in this context: Regards, Pete

Oh, right .... so you just want your FSUIPC key now? Please send me a short note with the name and email address you were using and I'll see if I can find it in my archives. Email to petedowson@btconnect.com. Obviously I can't deal with it here. Regards, Pete

WxGauge is perfectly okay. I don't know any current gauges by Mr. Dambrosio -- are they specific for FS2004? Do they use FSUIPC? Do you have any GAU names? Please perform a process of elimination -- take each gauge out of the GAU folder, one at a time, and thus identify the culprit. I really think you will need to get support from whoever is the author of whatever is causing you a problem, but you need to identify it correctly first. I have already spent a lot of time on WxGauge because of your message and I also notified Florian of a problem, so he is probably wasting his time too. I already told you, please check back to where I said "zip up both logs and send them to me at petedowson@btconnect.com". Regards, Pete

No logs received yet. I've now obtained the WXgauge and tested it, and it works fine with FSUIPC 3.40. Looking at what the gauge is doing, I can honestly see nothing likely to cause any problem at all. I think you have to look elsewhere. Regards, Pete

Unfortunately the number 96 is derived from dividing the space available by the size of the data for each aircraft. The only way "N" will change is downwards, if more data is added, or upwards only if some data is removed. I can hardly remove data now, or a lot of programs will break. Bearing in mind that the main object was to provide data for TCAS gauges, ground-based aircraft are a secondary consideration in any case. The 96 nearest airborne aircraft are enough for any TCAS gauge, really. Perhaps, for ground-based aircraft, rather than give priority to "nearest" I should select the 96 in the most advanced stage -- i.e. those which are moving or have approved clearances at least. Then, of your 144, the only ones you won't see will be "sleeping". Would that do? Regards, Pete

Really? I don't know of any problems either way. They are simply not in conflict, unless your GoFlight equipment includes throttles and gear levers and so on which you may also have on the PFC units. If you have duplicates then you just have to choose. Superb. Better than anything else I have tried, and I've tried most. Twitchiness can normally be overcome by calibration and application of slopes (e.g. as in the recent FSUIPC releases -- as well as in the PFC.DLL). But there is no comparison between the CH yokes and the PFC ones. Naturally a column yoke has easier elevator movement than a dash-mounted yoke, simply because there's so much leverage, but there again you've got more distance and therefore more sensitivity. Great! I have a Cirrus II as well, and it is good but I far prefer the column yoke for airliner flying. It isn't 'heavier' in the elvator axis of course -- it shouldn't be. But it doesn't feel "springy" either. Just nice, very easy to use. You download FSUIPC from http://www.schiratti.com/dowson. I don't supply anything but technical support and more developments. You don't need a user-registered FSUIPC to run the PFC driver. The PFC gear may come with a copy of both FSUIPC and PFC DLLs but always check for updates. Regards, Pete

Best to get them direct from your backup of the FSUIPC.KEY file, or maybe a printed copy of your receipts/notifications from wherever you purchased them. If you've not got either, then you need to go to your supplier. I don't actually supply the keys and do not have copies of any issued by any supplier. For SimMarket go to http://www.simmarket.com and open your account there. I think then the keys are directly retrievable. Please take good care of things you pay for. Computer crashes are almost inevitable, you must never keep only copies of anything there. Regards, Pete

But it is off by default, and actually needs a deliberate INI change to enable it. Furthermore, except for a correction in version 3.30 to make it work correctly in FS2004, it has been unchanged since it was added in Version 2.00. Regards, Pete

Are you sure that's not GGA, which is supported? I've not heard of CGA and it doesn't appear to be listed anyplace. Check the NMEA FAQ site, for instance, at http://vancouver-webpages.com/peter/nmeafaq.txt. Maybe it's a proprietary one, in which case you'd need specifications from the makers, or it's a brand new one. The NMEA 0183 spec is now priced at $325 so I'm afraid I'm not going to buy a new one. :( Regards, Pete

I'm really nothing specifically to do with SimFlight, they act as the retailers and deal with all the registrations themselves. Certainly, if it has been over 48 hours you should do something. I think they say something about filling in a "problem" ticket or similar? Have you checked? Please go to http://www.simmarket.com and take a look. If the email notification to you has gone astray you should still be able to open your account at that website and retrieve your key. The other possibility is that the payment for some reason has not been confirmed/approved. How do you know it has actually bee debited so soon? Best to check the correct procedures on the website itself. BTW you don't purchase one specific version of FSUIPC. The payment covers any version 3.xxx, so please do check now and then, and keep up to date as new versions are released. Regards, Pete

Yes, as far as GPSout is concerned you only need 2 wires really: TXout and Common on the PC to RXin and Common on the PDA. The pins on the PC are easy enough: 9-pin pin 5 = common, pin 3 = TX out 25-pin pin 7 = common, pin 2 = TX out In the unlikely event that the socket on the PDA looks like one of these (i.e. a D9 or D25) then it will probably match. In that case the RX in is pin 2 on a 9-pin and pin 3 on a 25-pin. But the PDA will almost certainly have it's own peculiar style of plug or socket, in which case the best thing is to use the serial cable that came with is and make an extension, wired as above, to connect to its PC-end plug. The trouble is you won't know without trying which of pins 2 and 3 to connect to. The other problem is that the PDA may insist on one or other of the control lines being "True" before it operates -- one or more of DTR, DSR, CTS, RTS again depending how it is configured. You may need to tie its CTS and RTS together and also its DTR and DSR, or some other combination. In PC terms: 9-pin: DSR=6, DTR=4, CTS=8, RTS=7 25-pin: DSR=6, DTR=20, CTS=5, RTS=4 Regards, Pete

Okay, that's good then. Now you need to see what the settings are in the GPS -- or are they fixed? Some GPS's only allow the "standard" serial speed of 4800 bps, as specified by NMEA. If so, you'll need to set that speed in the GPSout.ini. And is the GPS set to output actual NMEA protocol data? Is the software on the PDA set to receive NMEA data? There may be other protocols in use, including proprietary ones. Next is to make sure that the cable from the PC port to the PDA is working. Is it one you've used for other things? If not, it may be a direct rather than twisted cable -- the TX from the PC needs to be connected to the RX on the PDA. I think one of the sentences supported by GPSout provides such values, invented of course. If you don't know which NMEA sentences your software needs, then you'll need to try them all, then eliminate some (else it will be too slow, especially at 4800 bps). I can't remember which sentence type does what now -- I've got an NMEA protocol specification here somewhere (cost an arm and a leg!) but I've mislaid it, not found it in months. Best way to find out what your GPS is providing would be to connect it to a program which will display the data as it arrives for you. If you have no "terminal" program on the PDA, try linking it to your PC and using the Windows "hyperterminal" program to see what is arriving. If you want to see for yourself what GPSout is sending, you can actually monitor the PC serial port -- use PortMon from http://www.systeminternals.com. Regards, Pete

GPSout cannot handle anything at all. It isn't designed to handle anything at all. All it does is turn Flight Simulator into a GPS and outputs the standard NMEA signals almost any GPS does, and on the selected serial port. The NMEA standard defines the messages and the format, and it is for serial connections. GPSout has no idea what is on the other end and doesn't care. It doesn't receive anything, the protocol is 100% one way, PC serial port out to whatever you connect it to. The normal receiving end, on the other end of the serial cable (just 2 wires, basically) would be another PC running a moving map or similar -- just the sort of thing you'd connect a real GPS to. If your "Pocket" PC resembles an otdinary PC enough to have a normal serial port and you have software for it which can receive NMEA sentences on that serial port, then you might be able to use it. Try it with a real GPS instead of FS + GPSout. Does that work? You may have to make a special cable. I don't know anything about PDAs so I cannot really advise further. Sorry. Regards, Pete

It doesn't get any freezes here I'm afraid. In fact it runs very well, good frame rates. Regards, Pete

Not necessarily. if the values are there and useful, then someone somewhere will know what they are and how to use them. Most of the engine and performance values already in the FSUIPC offsets list were derived and proved by individual aircraft expert users, not resolved at all for me by Microsoft. Regards, Pete

Well, if you find exactly what they do and need support from the variables, in FSUIPC offsets, let me know with enough explanation and I'll put them on my list. Regards, Pete