Pete Dowson

Yes, the reason the FSUIPC_Process call is separate is so that you can build up a complete set of requests -- as much as 30k data (including overhead data, 16 bytes per Read or Write) can be accumulated -- for one transfer to/from FSUIPC. All the read/write stuff is actually in your program, and very fast. But every Process call requires a process switch to FS and a switch back to your program after. So each such call can be 100 or more miliiseconds. Compared to the time for the actual data that is huge. It is even worse of course over WideFS where you add Network latency. Ah, okay. I see that now -- I missed it on my quick perusal. Regards, Pete

That's pretty easy to do, since the NWI effectively gives you a clear interface directly into WEATHER.DLL functions. FSUIPC doesn't check your data nor place any restrictions on it, since I didn't want to restrict exploration. For example, there are only so many cloud types selectable -- if you try one which has no graphics defined for it, crash. There are probably more ways to crash FS with erroneous data than you can shake a stick at! ;-) Best when developing new software to test it on the FS PC first. That is most definitely a problem on your Network. The data is checked thoroughly on reception to ensure no rubbish is seen and obeyed. The crash is at 2112C218 which is in WEATHER.DLL, and just a glance at the weather you are trying to set shows the likely reason -- Cloud Type 3 isn't implemented in any standard FS at present. I don't know if it can be added by clever folk like those who do the cloud graphic replacements. Your main task is checking the data you are asking FS to obey. Yes, the entire method is different there, and FSUIPC will replace any invalid cloud types with valid ones. I knew FS2000 and FS2002 Weather implementations quite well and could therefore impose restrictions without qualms. With the whole weather engine in FS2004 being new, a complete re-write, I didn't want to restrict experimentation. The consequence is that you have to check the data because FSUIPC isn't babysitting you on this. Regards, Pete

Help what? I can easily get the number of miliseconds count. I use it all the time -- see any FSUIPC Log, for example. But that is NOT the same as FS time. FS time is simulated time, it isn't necessarily closely related to the real elapsed time at all. The GPS data output is supposed to be the simulated time of the simulated position, not any real time. I don't know where the NetPipes gets its time "between frames", but I also do not know when a "frame" occurs, so even if I knew it, what would it mean? So how do you propose using this NetPipes idea? You seem to have misunderstood my previous explanations. The milliseconds I am using to fill in the fractional seconds IS accurate, at the time I stamp it. It is just that is it the time from an arbitrary zero fractional moment which I cannot pinpoint since I cannot detect exactly when the second count increased. The other inaccuracy from the receiver end is the unpredictable delay from when I stamp it to when you receive it. If you think Netpipes has the answer why not write your own GPSout program using NetPipes and see if that gives you more accuracy? From what I've heard about that FS facility it is anything but. Pete

Help what? I can easily get the number of miliseconds count. I use it all the time -- see any FSUIPC Log, for example. But that is NOT the same as FS time. FS time is simulated time, it isn't necessarily closely related to the real elapsed time at all. The GPS data output is supposed to be the simulated time of the simulated position, not any real time. Pete

I've had a brief look. First thing -- your code will be EXTREMELY inefficient. You are reading all 96 slots for both ground and airborne traffic, all individually. This involves 192 separate Process calls, which is 192 separate Process switches between your program and FS!!! Please think about that and compare it to a method which has two arrays of 96 TCAS structures and does one read of 96 x 40 bytes for each, and then one Process. That will take about the same time as just one of your 40 byte reads -- i.e. 192 times faster! Then your loop to read strings reads them for every slot, even empty ones (Id == 0). Furthermore, you are writing the Signature to D00C, immediately overwriting the Aircraft ID you just wrote. The proper signature offset D000 is never written, so no command is ever obeyed. Please consider debugging code before thinking FSUIPC is in error. If your own compiler's debugger isn't any use, at least use the tools FSUIPC provides - checking the actual sequences of writes and reads in the Log would tell you everything. Finally, please note that this method of reading all the strings is grossly inefficient for what you wish to to. It was implemented to help programs like Radar Contact name the *one* aircraft in front of your own in a queue for take-off, and things like that. For your purposes, why not use the Aircraft ATC ID string which is provided in the TCAS tables already? If you want a specific one, read the current settings from E068/F068 areas, then set the ones you eant, read all the TCAS tables (in one Process), then restore the previous settings. I know the strings you get that was are rather abbreviated, but I'm sure you could work it to your purposes and end up with a much more efficient program. Regards, Pete

What's an "FSVPI" custom licence? Please always refer to the latest version, which is dated 25th April (it is the one which matches FSUIPC 3.48). Of course it will be zero initially, before anything has read anything. The timestamp is set to indicate some data has been made available. Until an operation is performed on it to read something, it won't be set. Can you not see that is perfectly logical? Why would you want to skip any steps? Instead of trying to explain in words here, please use FSUIPC IPC read/write logging. That is what it is for. From the logging we can both see exactly what is being written and read and can analyse what is going wrong for you. I don't know how you'd want to get the "visual information". The type and model won't tell you the livery, for instance. The string which is used to actually SELECT the aircraft in FS, the string which is saved in the FLT files for this purpose, it the aircraft title, so you may want that. It could be anything, but if you have the same aircraft installed in both systems it is the string which conclusively points to a particular model and texture set in the installation. All the strings are from declarations made in the Aircraft.CFG files, so perhaps you can look at some of those to see what you need? Not without more information. Please try using some of the tools provided. In this case a short part of the FSUIPC Log with IPC read and write logging enabled would explain everything. That's because the SDK was only updated after the facility was added (in 3.48 ). You could check the History documentation enclosed with the FSUIPC package, or just look at the "Recent Release Changes"announcement near the top of this Forum, which shows the same data. I think you'll find it as item 8 in the 3.48 changes. But the best thing is to always keep your SDK up to date. Regards, Pete

Though there haven't been many (considering the number of registrations), I can assure you that in 100% of cases like this, so far, it has been an error on the part of the user not entering the data correctly. As it says in the email you would have received you must enter the name, email and key EXACTLY as in the email. It is surprising how many ways folk have of spelling their own name. Computers don't understand all that, they need the exact data. It is best to cut-and-paste from the email so you make no mistakes. If you believe you are doing it all correctly, please send me the details (preferably the actual email you received) to petedowson@btconnect.com and I'll check it here for you. Regards, Pete

AhI don't think the actual intervals will be more accurate. As I said, I cannot tell when FS increments its seconds counter. The only accurate intervals will be from the readout with zero fractional seconds to each subsequent one in that second -- the interval from the last fractional value to the next whole second will be inaccurate because the latter is just when I see it as changed. Furthermore, I can only time it when I deliver it to the Windows buffered file system for the attention of the serial port driver. I suspect the time between then and it actually going out could vary by more than the interval iyself. Regards, Pete

Yes, and I have just spent some time answering you there. I'll need now to repeat it here for others' benefit. I'm not sure what could be doing it, but one possibility is an FS memory leak. Check the memory use (in the task manager) -- compare it when it is performaing well, early on, with how it is later when it seems so slow. I think lack of physical memory will affect the way the Windows socket buffering operates. There are a number of causes of memory leaks in FS. They are far less if you are using 9.1 rather than the original 9.0 release, but some still exist. One famous one if when you have landclass BGL data in the Addon Scenery folder. I had to move a whole bunch of freeware scenery from there to the normal scenery folder to get rid of one such case. Please always check the Announcements and Stickies at the top of this Forum! As you would then see, 6.47 is the current release, though there is a Beta pre-release also available (it will come out as 6.50 shortly). But there's no change I can think of which would affect what you are observing. Regards Pete

I attach GPSout 2.584. Try it. I've taken your word for it that receiving programs shouldn't be upset by the 6 decimal places for Lat/Lon, but I've added a parameter as well -- "PosTo6Decimal", which should be set to "No" to make GPSout revert to 4 places. Currently it will default to 6. The fractional seconds are being set to the number of hundredths of a second since I last saw a change in the Seconds value. This is being done just before sending the data out, so it's the most accurate I can make it. Let me know how you get on with it. Regards, Pete GPSout2584.zip

I'm not sure what "simulated" window mode actually means. Are you running something like FS Real Time or similar which is set to correct the time? That's the only time I see such things -- if the time is adjusted by more than a few seconds, FS will reload textures. It's to do with its time of day or shading algorithms I think. Doesn't this occur in Windowed mode too? If not then my guess is wrong and your other advisors are correct, it's to do with your video card and its drivers. It sounds like their memory "expires" and their huge cache of textures needs reloading. This is one of the problems of large memory video cards -- similar effects can be obtained with sound cards which do a lot of wave file caching. But I've no answers, except to (a) run in Windowed mode instead -- there is, these days, usually no penalty apart from the title bar at the top of screen, which can be kept very small at high resolutions, and (b) why go into the Menus in any case when flying? If you are not flying at the time, then surely the time spent for FS to sort itself out is nothing to get upset about. If you are flying then using menus is extremely unrealistic and disruptive in any case. Sorry if you expected more from me, but graphics and video behaviour has never been my subject at all. Regards, Pete

Yes, I can do that. Just more work, is all. ;-) I understand all that, but with FS the only smooth thing is inside FS itself. Once you bring in other threads trying to multiprocess, and operations via asynchronous serial links, I don't see how such precision is anywhere near attainable. Check it wourself -- are your 100 mSec intervals working out at even close to 100 mSecs? If your main processor and video cards are underloaded, and you don't have very detailed scenery or complex panels in FS, then maybe it will be regular enough. Of course, but it is because that's where the priority lies that other activities don't necessarily get time when they would otherwise want it. Well, I think the best I can do is, when I see the FS second value change, reset a millisecond timer, and adjust subsequent times in the sentences accordingly. This would essentially be a fictitious time because I don't actually know WHEN FS changed its seconds value. Of course. That wasn't the problem -- you misunderstood what I said. I can "invent" the fractional seconds in the way I just described. They just won't necessarily be related to FS's actual time correctly. Regards, Pete

Done. Thanks! Pete

If there's no short cut key for them, the only way is to have something that produces a mouse click in the right place. Luciano Napolitano's "Key2Mouse" program comes to mind. You'd then program FSUIPC to make the button send that key. Regards Pete

Why bother with the Advanced User's manual? Just go to FSUIPC options in FS, Buttons page and program it there. There's no point in making easy things hard! If you select the Offset Word Setbits control in the dropdown you can enter the offset (x050A) and the bit value (1 in this case) directly. Anyway, in this case, because the PM document says "Bit Toggles" I think you need to toggle the bit, not just set it. So use the FSUIPC control Offset Word Togglebits instead. Pete

Erthe log entries you *should* be getting with that option look like this: 229125 *** AXIS: Cntrl= 65762 (0x000100e2), Param= -16383 (0xffffc001) AXIS_ELEVATOR_SET 234765 *** AXIS: Cntrl= 65762 (0x000100e2), Param= 16383 (0x00003fff) AXIS_ELEVATOR_SET 253812 *** AXIS: Cntrl= 65763 (0x000100e3), Param= -16383 (0xffffc001) AXIS_AILERONS_SET 298906 *** AXIS: Cntrl= 65763 (0x000100e3), Param= -16383 (0xffffc001) AXIS_AILERONS_SET 303656 *** AXIS: Cntrl= 65763 (0x000100e3), Param= 16383 (0x00003fff) AXIS_AILERONS_SET The calibration messages come from an entirely different option, originally put into FSUIPC for Aerosoft (Australia) for their GA-28R Piper Arrow III cockpit (of which I have one of the only five made, I think)! ;-) Check your FSUIPC.INI file. There's a parameter "AxisCalibration=No" -- it sounds like you must have that set to "Yes"! The calibration is done when you have this as "Set". This enables automatic calibration to occur when FS is first loaded by moving all the controls to each extreme. This is how it is done for the GA-28R (I think some others do too). A section in the INI is generated called [AxisCalibration] and the values placed there. I don't know how or why you have that parameter set, but if you don't want to use the facility (and it certainly sounds like you don't, delete the section and change the parameter back to "No". HmmmI'm not sure about any of that. Those "something's" were probably "SCALE" and represent the sensitivity slider positions in FS -- but I can assure you, those do not affect stuff written directly. I have tested that conclusively by setting all sensitivities to zero and all null zones to max, which should well and truly clobber all the axis inputs, but it has no effect whatsoever on these direct inputs. Regards, Pete

The sensitivities and null zones are ONLY applicable to true joystick inputs. You most certainly do not need real joysticks or dummy ones. The controls are what happens AFTER all that stuffas I thought I explained? It uses pretty much the same system you are using. There is certainly no problem on a system which has no joysticks -- in fact most all PFC installed systems have no Windows type joysticks and never have had any. I repeat, there is no need to have any real joysticks, and never has been. You do not need them or dummy ones. Something else is going wrong, you need to check your system as I suggested. There are plenty of tools provided for you to check! Pete

Hi again Tuomas, One thing I should warn you about since you are wirting direct to the control offsets. Aircraft panels with their own A/P and A/T such as PMDG and PSS, and external autopilots such as the Project Magenta one, will not work too well with such a system unless you take steps in your code. For throttles, in the Beta FSUIPC I provide a facility for an alternative set of offsets: You'd be best off using these for throttle control so that the AutoThrottle action can still override as needed. For the main control surfaces when the A/P is engaged you may need to simply not move your controls (and trust they are stable) -- in a real airliner I believe sufficient control movement disconnects the A/P in any case, so perhaps that's what you'd need to do too. Regards, Pete

BB6 and BB2, you mean I hope? But turns out I have a problem now: The controlling works right. But it is a lot like when you set "sensitivity" to very low in FS in the joystick options. I can see from the iocards monitoring software that both fsuipc variables seem to move the full range (-16383 to 16383) - but the control surfaces in FS do not move much. Thus control sensitivity is very low. I assume this is with FS2004? I cannot see how that is possible, as, since FS2002, the only way FSUIPC has of effecting those controls is by sending the values directly as parameters to KEY events such as KEY_AILERON_SET, whch are the same as would result from a normal joystick input, after FS's calibrations sensitivities and null zones. I get a full deflection here, fine. I don't know what you are doing wrong, but have you checked with FSInterrogate, or even used logging in FSUIPC to see? Check in any case with a default aircraft -- some of the more sophisticated ones do intercept some of these controls for "fly-by-wire". The Axis logging in FSUIPC won't log these by default, since the method used to send the controls by-passes it, but if you get the latest Beta (see top of Forum) you can force FSUIPC to log your axis changes too by changing the FSUIPC.INI file as follows: Add to the [General] section Debug=Please Then, after loading FS, go to FSUIPC's logging page and set Axis event logging on, and "Extras" to the value 16. Always compare what you are doing with what can be done simply in FSInterrogate, and also just using the keyboard Num keys to raise/lower elevators and so on. Regards, Pete

The NMEA 0183 specs I read seem to specify 4 places explicitly. If I change that it may muck up some receiving programs. Is this a change in a later version of the specification? Since the current "accuracy" of 1/10000th of a degree is, at worst, only 36 feet (and that, for longitudes, is at the equator). I'm not sure there's a lot of point in going further with FS as the timing of you receiving the data is going to vary far more significantly -- unless the thing you are tracking is very slow moving, like a boat? If I could be sure that it would not upset any other receivers I could add two more digits though. There's no fractions of a second in FS's time of day. If I "invented" them, what should they be? Just add something now and then? It would make little sense. I don't actually know the instant FS updates its second counter. Although there is a millisecond counter internally I think that carries on regardless of FS's simulation rates and so on. It wouldn't be the precision of the Lat Long but the lack of any precision in the timing. Expecting your data to be precisely every 100 mSecs apart when it can take longer to do a process switch or suffer a delay through thread timings is possibly a little bit optimistic I'm afraid. Regards, Pete

Sounds like it's license has expired? Otherwise you really need to check with PM support -- I cannot support their programs. Sorry. In any case I would need more details. The Log you supplied shows nothing because it isn't finished - no errors are shown, nothing really useful is shown, except maybe this: 172 Opening GPSout port COM1, speed=4800 -- FAILED! which is due to an error in the Beta wideClient -- if you don't add a GPSout section to the INI file it does it for you, but it shouldn't. I have a later version which fixes this, but in your case it shouldn't do any harm in any case as the COM1 port is evidently either already occupied or it doesn't exist. Does your PM MCP directly connect to anything on a serial port? Please always close down the relevant programs before showing a log. An unfinished log is not often useful. Regards, Pete

Yes, that is the one added to get around the ERJ145 problem. Ah, you didn't look carefully enough then ;-). Just searching on _SET for example, or scanning the Joysticks section for the table showing all the controls, would have led you to the bit in the table on the separate Throttle controls, and the explanation is in the right-hand column there, viz: Oddly, in the 5 or 6 years FSUIPC has been operating this for both older and newer axis controls, only two instances of aircraft panels actually using the old ones (for their own purposes) have arisen -- and both in the last few months! Regards, Pete

At a guess, it sounds like you are using FSUIPC for multiple throttles, posssibly to get reverse on the same levers, and haven't set the cirrect options? Without a lot more information I would have no other ideas. Instead of simply removing FSUIPC altogether why don't you try simply resetting your throttle calibrations and mapping in it? If you don't actually ask FSUIPC to do things it doesn't do them. In the next version (3.50) you can have different joystick settings in FSUIPC for different aircraft, so you could then switch the throttle stuff off for the MD80 without losing them for everything else. If you want to try that there's a Beta version available at the top of this Forum. BTW the AVSIM reference you provided also included this paragraph: Perhaps you missed that bit? The option mentioned is at the bottom of the separate throttles page of FSUIPC 3.48 onwards. Pete

I'll look on my Win2000 installation. It may not be called that anyway -- it wasn't called that in earlier versions of Windows in any case. [LATER] In my Win2000 Pro installation the joystick settings are in Settings-Control Panel-Gaming Options. Please try changing the ButtonScanInterval=20 parameter to ButtonScanInterval=0 in the [Config] section of the WideClient.ini file. That will stop Wideclient looking at any buttons, whether Windows or GoFlight. Regards, Pete

That's really good to know. Thanks! Is there some place you could post this on the PMDG support forum too, please? Good flying! Pete