Pete Dowson

Just a question on this: With a flight one day then the next, as well as FSUIPC changing from 3.50 to 3.51, the weather set by ASV would have changed too. In the last part of your statement above you imply that you had virtually the same weather both times on the second day. Is this so? Can you actually be sure to use the same weather, so there is a direct comparison? That is possible with ASV, isn't it? I've checked and double-checked and the differences between 3.50 and 3.51 in the area of winds are really very very small and cannot account for what you are reporting. I need to be absolutely sure it isn't more due to a specific set of data. The other reporter ("jbinner") reported "... the winds on the east coast are still fairly rough with large gradient shifts". I notice you are on the East coast too. Was that where you were flying? I'm concerned now that all this fuss is really more due to unusual real weather conditions or rather unusual or erroneous data in ASV's weather server -- ASV and the East coast seem to be the common factor between the only two reports. Oh, I've just noticed -- "jbinner" was actually flying with FSUIPC's wind smoothing switched off. That makes your experiences unique at present. Regards, Pete

Did you check to see if there was any "wind variance", gusts or turbulence being added by ASV? These are all possible and are not normally affected by FSUIPC smoothing or other options, except outright suppression in the latter two cases. Ah .. no gusts. But what about turbulence and, especially, wind variance? (You might need to run WeatherSet2 to see variance values). Regards, Pete

Can you include your FSUIPC.INI file, and the FLT + WX files too please (the last AutoSaved ones if you use that, otherwise could you refly and save the flight for me)? There's really been no change which should do this, quite the reverse in fact -- there was a particular case when in versions earlier than 3.507 it could generate windshifts at the aircraft even though they were not apparent in the weather reports. There have been at least 20 folks flying with programs like ASV and FSMeteo with 3.51's release candidate for several weeks, and I've had no other reports until these two today. It is most odd. I have flown with Radar Contact and ASV many flights over the past few weeks (first time I've managed so much flying for ages!) without any wind shifting problems. I can't understand it. :-( All I can do is promise to look at the logs and any other data when I receive it. I may have to ask for more tests with different logging options or even with special test versions of FSUIPC. Regards, Pete

Hi again, I've just done some more scientific tests on wind smoothing, and it seems to work perfectly. I set winds 270/30 at EGCC and 90/30 at EGGP, about 30 miles away, enabled weather logging and the Shift+Z display and flew from EGCC to EGGP. The smoothing did exactly wehat I asked of it in the FSUIPC Winds page. Without FSUIPC's smoothing the changes were more jerky -- not exactly a 180 degree sudden change, but in jumps (according to the Shift+Z display) of more like 30 degrees. I think this is FS's own idea of "smoothing". It sounds to me as if you haven't got FSUIPC's wind smoothing enabled. You didn't delete your FSUIPC.INI file when you updated to FSUIPC.DLL 3.51, did you? If so you'll need to re-establish all your options the way you like them. Also check the options in ASV. I think it overrides some of FSUIPC's settings. Regards, Pete

No change I know of. Can you repeat with Weather logging on please? Save a copy of the log as soon as you get such an effect, and ZIP up the Log as it will be rather large. Send it to me at petedowson@btconnect.com. The version 3.51 that was released generally yesterday has been available as 3.507 for many weeks here, in the "new versions" announcements, and has been extensively tested by many folks over a number of weeks, with ASV as well. I use ASV myself and have had no similar problems over many hours of flight. Regards Pete

In FS2002 all weather programs could do was set Global weather -- i.e. set the weather the same everywhere. As you fly, the weather, everywhere, is changed by the weather program. Therefore the weather at your destination is actually the same as the weather at your aircraft. It would be this that ATIS reported. Weather programs like FSMeteo and ActiveSky had options, for use with FS2002, to set the destination weather at a given number of miles out from the destination, so that you would know what it would be within that range, and the ATIS would be correct. For programs such as Radar Contact, which had their own ATIS reports and runway assignments, FSMeteo made special arrangements to supply them the destination weather without having to fix it in advance. I don't know if any provision was ever made in FSMetar for these things. The problems don't arise in FS2004 because FSUIPC is able to set localised weather, and programs like FSMeteo and ActiveSky make full use of these facilities. No, only in FS2004, and then only if the weather program makes use of the new localised weather facilities. FSUIPC is kept compatible with all of its previous versions -- even FS98 programs should still run okay, provided either that you purchase a user registration, or the programs concerned have an access key. There is an Access Key provided for FSMetar, but I don't know if it is built into versions 1.54 or 1.55. If they are the most recent then you should be okay. Have you tried wind smoothing in FSUIPC? Regards, Pete

No, no, sorry, I didn't mean to imply it was any fault of yours. It's a recurring problem on the Internet, and it varies a lot from ISP to ISP. The problem derives from the habit of ISP servers caching popular files to save obtaining them for each request. The should check reasonably frequently whether the file has actually changed (eg by timestamp), but it apears some do this much less often than others -- in an extreme case it might take a day or two for them to catch up! There's not a lot we can do apart from possibly rename the file each time (eg FSUIPC351.zip), but that then breaks a lot of links helpful folks have placed on other websites. Regards, Pete

Yes, that is what I meant by using a database of stations. If you didn't mind tuning into the VOR on an FS NAV radio first, then click a button or something to tell your program "this is the DME" (assuming it is a VOR-DME) then you could have that program carrying on giving you DME info for that station even after you re-tuned FS's NAV radio. There is certainly enough information available from FSUIPC for all this, and the "triangulation" problem is pretty simple trig if you assume you are close enough to the station to use planar geometry rather than spherical. This way you wouldn't need your own VOR database. Regards, Pete

No. FS has its DMEs tied exclusively to its NAV radios. There's no way possible unless you invent your own DME program with a complete database of VOR/DME stations. Regards, Pete

Ah, the inevitable! ;-) Some people say that every time!!! Refresh your cache, try Ctrl F5. If that doesn't work you will have to wait until your ISP catches up. Regards, Pete

"FSUIPC.Log" you mean? There has been absolutely no change to the key checking, except for the rejection of a few more keys of those who have broken the rules and published their keys, or have obtained a refund on their credit card after purchase and receipt! (Tut tut! ;-)) Please ZIP up your FSUIPC.KEY file, together with details of your purchase if possible, and send to me at petedowson@btconnect.com. I will check it immediately. Do not send any files unzipped please! Regards, Pete

fsuipc.FSUIPC_Write(0x3380, bytes.Length, ref bytes, ref token, ref dwResult); fsuipc.FSUIPC_Write(0x32FA, MsgTTL, ref token , ref dwResult); But I still can't fathom how the same call (to FSUIPC_Write) can take 5 parameters in one line and 4 parameters the next. Your C# compiler obviously doesn't care, but how on Earth can the routine that is being called tell which parameter is which? For example, "dwResult" is the 5th parameter in the line to write to 3380 but the 4th in the line to write to 32FA. And what are you actually writing to 32FA? You missed the length, so "10" will be the number of bytes transferred, not the time to be held! And what is this "magic token" for? And why oh why has Microsoft invented a language which appears to bear no relation whatsoever to C and called it C#? Makes no sense to me at all. :-( Sorry. Regards, Pete

WideFS has nothing whatsoever to do with downloading weather nor flying on-line. WideFS is for Networked PCs, to allow you to run FSUIPC applications on other PCs. WideFS won't run unless you've paid for it, so I don't know wehat you are thinking of updating? Regards, Pete

Sorry, I'm afraid I know nothing about C# -- it doesn't look anything like C! But this seem's rather odd: fsuipc.FSUIPC_Write(0x3380, chars.Length, ref bytes, ref token, ref dwResult); fsuipc.FSUIPC_Write(0x32FA, 2, ref token , ref dwResult); Both are calls to FSUIPC_Write, yet the first has 5 parameters and the second has 4. does the C# compiler allow this sort of inconsistency? I've no idea what that token thing is, but you don't appear to have a reference to a value being written in the second Write. I assume 2 is the length, was token supposed to be the value? [LATER] One other thing: string chars = "Message Text0"; UnicodeEncoding Unicode = new UnicodeEncoding(); bytes = Unicode.GetBytes(chars); I don't understand much of that, but: 1) does "bytes" end up holding a string of 8-bit (byte characters), NOT Unicode? If the Unicode value (16-bit) is being sent, then the second (high) byte is probably zero which would end the string, resulting in your 'M'. 2) Is the "0" at the end of "Message Text0" meant to be a zero terminator? It won't be, it will be the character zero. In C strings defined with "" have zero terminators in any case, but these aren't included in the length. If the same applies in C# then your length value needs 1 adding. If the same doesn't apply in C# you need to add the zero byte. In C this would be by \0 or \x00. I don't know if C# has an equivalent way of getting actual values into the string. Regards Pete

Surely you aren't asking FSUIPC to add random turbulence when using a weather program? You should leave it up to that. In any case, no, these things aren't additive. If it is only on approach are you sure it isn't wake turbulence from the aircraft in front. I know ActiveSky has such an option. Maybe FSMeteo has to and it is enabled? If you don't like the turbulence, why switch it on everywhere? If it is a wind direction change, try using wind smoothing. Very unlikely. That was for gusts, and I only added it because one Log from an FSMeteo user showed a gust of some many hundreds of knots. I think it derived from some bad data download and a signed/unsigned mismatch. The limit in FSUIPC is a safety precaution, that's all, and shouldn't be invoked in normal circumstances. Regards, Pete

Yes, but you can tell VERY easily by just seeing different button numbers register in FSUIPC's buttons page (centre, top -- gives joystick number and button number). I have just connected a device with several buttons, programmed 4 of them for the separate engines 1 & 2 Rich and Lean, OKayed out of FSUIPC, then brought up the default 737 throttle quadrant and tested their action on the start leverls botton central in that graphic. they operate perfectly. Show me the Buttons section of your FSUIPC.INI, and confirm what button numbers you get on operating those 'levers'. You could also log the results of pressing the buttons -- see Logging pages, select the ones for logging buttons and controls (non-axis types). Regards, Pete

Erthese "buttons" are in fact toggle switches, not buttons? Do they actually have separate button numbers when pushed up from when pushed down? It doesn't seem very likely to me, yet that is how you say you have programmed them. It sounds like you've programmed them only to set Lean, overwriting the Rich settings? Please go back into FSUIPC's buttons page and review what you have actually done. If the switches are actually seen in the PC as ONE button, you can only program them ONCE. You program one value for "Press" and the other for "Release". I wouldn't know whether your switches are "on" when up and "off" when down, or vice versa, but "on" is "press" and "off" is "release". Regards, Pete

This version is really very old (getting on for two years!). I cannot support old versions. Please download the latest from http://www.schiratti.com/dowson. Current is 3.50, though later today version 3.51 should be available from the same place. You seem to have turned Weather logging on. Please don't unless there is some problem with weather that you are looking at. Unfortunately, the aircraft problem you have is not resolvable with any freeware (or payware) access key. This is the reason: 380922 Client Application: "fs2002" (Id=332) 380922 C:\Program Files\Microsoft Games\FS2002\fs2002.exe 380922 Product="Microsoft Flight Simulator 2002" 380922 Company="Microsoft Corporation" 380922 Illegal read attempt: offset 0B78, size 4 FSUIPC is indicating that the PROGRAM making the illegal call is FS itself. This means that the Gauge is using an external method to link to FSUIPC. This has NEVER been legal or correct, and such a gauge cannot be accredited. This has been the case since soon after FS2000 came out, so I suspect this aircraft, or at least some of the gauges in it, date from FS98 or early FS2000. You have two choices. Either pay for FSUIPC user registration, or do something with that aircraft (AIRCRAFT\L100-30B\c130.air). Either not use it, or find the culprit gauge and remove it. This is a helpful clue: If you look in the Aircraft's PANEL folder, you will find a Panel.CFG file. Load it into an editor, like Notepad. The parts you are selecting with Shift+1 to 4 will be indexed near the beginning. From there, looking through, you can find the part which Shift+4 should operate. It will have a number of Gauges listed for loading. One of those will be performing the illegal access to FSUIPC. That's because FSUIPC only shows the error message box the once, so you know it is rejecting all calls from the culprit gauge. The log may still fill with its illegal entry attempts, however, and whatever it is that it is trying to do will not be working. Judging from the locations it wants to access, the gauge is some sort of fuel monitor, possibly also a re-fueller/jettison control? This should make it easier for you to find and remove. If you do remove a gauge remember to renumber the entries for any following gauges -- they need to form a single sequence. And please update your FSUIPC.DLL before coming again. Okay? Regards, Pete

Offsets do not "correspond" to controls. Offsets are generally values, controls are, well, controls. You can send any controls through FSUIPC via offset 3110. There is a list of controls provided in the FSUIPC.ZIP file. Regards, Pete

Have you checked the obvious -- does the mixture lever actually work in FS? If not then it sounds simply as if you have the Sensitivity set to zero. Look in FS's Options-Controls-Sensitivities. FSUIPC will only see what FS sees. Pete

Can you be more specific? What is he reading for this, and how? Here I can set either Cloud or Wind turbulence in FS's weather dialogues and read it out through FSUIPC's interface. I can also set these values through WeatherSet2, though the Wind ones tend to be changed (mollified) by FS quite quickly after they are set, depending on the overall weather conditions around. The cloud turbulence 'sticks' better. Regards, Pete

Have you calibrated the Reverser axis in FSUIPC and forgotten to select the option to have it only operate for jets? By default the mixture axis is used for the reverser. Pete

Show me it then so I can interpret it for you. Normally it is pretty clear, but if not then I can help, given specifics. By the way, I too have never designed aircraft, panels, gauges or scenery, and I know very little about them. Your best recourse for any add-on aircraft which won't run is the author, as he is the only person who really knows what it does, what it consists of. All I can do is try to help you identify which part of which aircraft might be responsible, but even then some are written in ways that even that is impossible without trial-and-error, disabling each gauge in turn. Just show the log, we'll take it from there. You must surely know which aircraft is responsible, as the error will only occur when you try to load it. Regards Pete

What is AirnavFS live traffic? Is FSUIPC support needed for it at all? These are things you need to ask the author really. FSUIPC doesn't make any weather for you to turn off. It is only an interface for other programs. Please read the documentation I supply. Weather programs setting FS weather through FSUIPC will take care of themselves normally. Why not refer to their documentation? They should tell you what they do and how to use them. I've no idea, but it isn't very likely unless they need FSUIPC and don't have accredited access. Regards, Pete

Okay -- all's well that ends well! ;-) Pete