Pete Dowson

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

It isn't my subject, but isn't the VB .Net Shell part of the FSUIPC SDK useful? Regards, Pete

It's likely to either be a bug in FS, or one in the PSS gauge code, but one which is probably either very timing dependent, so a clean tidy new faster install doesn't fail, for example, or which is derived from uninitialised data. Something as simple as entering a loop with a count of 0 or -1 (decremented) instead of some small positive number could easily produce such an error, and if that count is picked up from the stack or other uninitialised memory then it is just luck what the value was -- though it may well be consistent in a particular set up (because of how things are loading and running with that particular order of installation etc etc.) If the error can be reproduced on a test machine, one with, for instance, a debugger running on it, then it would be relatively easy to find out what is going on during that 20+ second freeze. But that's the thing -- reproducing it on a machine where you can do that. Anyway, I do have a copy of the latest PSS Dash 8 here now, and I will see if happens on my PC. If it doesn't then I'm afraid it is still dependent upon PSS tech support only. The other possibility is that it doesn't fail at all with the forthcoming official Microsoft FS2004 update, but we shall have to wait for that to tell. Regards, Pete

Well, it's only written as a test program for my FSUIPC weather interface, and provided as a free demonstration of what can be done. I'll note your request and maybe try to fit it in when there's nothing else needing attention, but I really cannot place it at any priority, sorry. Maybe this would be a good training exercise in FS application programming for someone? All the information needed to write such a small utility is available in the FSUIPC SDK. Regards, Pete

So there was something funny about the way the computer was set up, before? Hmmm. Strange. Maybe something very specific with timing. What about the others with similar problems? Have you told them so they can try to resolve it too? Regards, Pete

I'm afraid I know nothing about helicopters, so I am dependent upon others telling me what there is and what works. The drop-down lists in Keys and Buttons are simply taken from a table in FS's own CONTROLS.DLL. There are these variables which I never found any explanation for and haven't mapped: ROTOR BRAKE HANDLE POS ROTOR BRAKE ACTIVE ROTOR CLUTCH SWITCH POS ROTOR CLUTCH ACTIVE ROTOR GOV SWITCH POS ROTOR GOV ACTIVE ROTOR LATERAL TRIM PCT and these FS controls, which I don't know: ROTOR_BRAKE ROTOR_CLUTCH_SWITCH_TOGGLE ROTOR_CLUTCH_SWITCH_SET ROTOR_GOV_SWITCH_TOGGLE ROTOR_GOV_SWITCH_SET ROTOR_LATERAL_TRIM_INC ROTOR_LATERAL_TRIM_DEC ROTOR_LATERAL_TRIM_SET Whether any of these actually work or not, I don't know. Test them with a real helo model, not the FS2004 Robinson which I think has been implemented using a normal aircraft model. As far as the variables are concerned, if they are needed and likely to work I can probably find a way to map them, but I need some explanation first so I can understand a bit about what I'm looking for. Regards, Pete

Not without more information. I don't know this "CWR", what is it? * When you say "after a few seconds FS2004 goes in crash", can you elaborate please -- a few seconds of what? When you do nothing, or is there something specific? What sort of "crash" is it? Is there any message? What is happening on this "crash"? Does CWR use FSUIPC? Have you checked with support from the author about this problem? Please enable IPC read and write logging (in the FSUIPC Logging page), and run it once with 3.317 and once with 3.400, zip up both logs and send them to me at petedowson@btconnect.com. I will take a look. * [LATER] I now know what "CWR" is -- I didn't recognise it by that name, but as "WxGauge.gau", and, yes, it does use FSUIPC. Odd thing, though, nothing it uses has changed at all between 3.317 and 3.400. In fact, 3.317 is very similar to 3.40 -- a few additional user features have been added, but they will be inactive unless used. It is beginning to look at if there may have been a problem anyway in the Gauge which didn't cause a crash before simply because of some different memory arrangement (with things changing in size and so on). I'll check the logs and maybe ask Florian about this. Regards, Pete

Sorry, I don't understand. If all the tabs are visible then the whole dialog box is surely visible? The tabs stretch almost the whole width anyway -- or are they wrapping onto two lines on your system? FSUIPC uses standard Windows calls to make, size and display the dialogue box. No sizing or font selection or anything is done in any of my code, only by standard Windows routines and settings. And the FSUIPC code for doing it hasn't changed since version 2.00, several years ago, when the on-line options were first added. I can only think that something is your Windows system is wrong. Maybe something you've installed has replaced one or more of the standard system libraries, like COMCTL32.DLL? If you post in the FS2004 Forum and ask Katy Pluta about this, she might know how to go about fixing it. Quite honestly, I have absolutely no idea. Sorry. Regards, Pete

But as far as I know there's no NMEA protocol defined for USB, so there's no way that will be used for NMEA connections. The USB connection to GPS's and PDA's is for transfer of data, not for real-time updating of position from an external GPS, which is effectively what GPSout is simulating. The NMEA protocol appears to defined ONLY for a serial port. Check your GPSMAP 96 specifications more thoroughly and I think you'll find there's no way of getting it to track a position supplied externally via USB. Regards, Pete