Pete Dowson

Not a problem, thenthanks for letting me know so quickly. I was getting all prepared with some extra logging and diagnostics, just in case. I think, sometimes, ASV or FSMeteo may be generating too much "wind variance". This is abrupt changes in direction, usually reported as "VRBL" or similar. FSUIPC doesn't smooth these (though they can be suppressed using the option to suppress all gusts -- that suppresses gusts and variance. I may add another option in the next version to limit the wind variance, possibly with the limit being inversely proportional to the wind speed. For example, something to give roughly these limits (only probably derived by a formula, to give a smoother scale): 0-5 knots, no limit (360 degrees allowed: i.e +/-180) 5-10, allow -90 to +90 10-20, allow -45 to +45 20-50, allow -22.5 to +22.5 over 50, allow only -10 to +10 Any comments? Regards, Pete

Okay, but try thingsyou can't do any damage. And then, if it doesn't work, come back with what you tried and we'll take it from there. It is much easier to help with specifics than a big amorphous unknown, which is what I see at present. There are too many things I don't know about the program you want to use and how it might be set up and worked. If it works fine by you pressing keys on its PC's keyboard, then the first, simplest, method I mentioned will be fine. Try it. Regards, Pete

No, sorry, there are no "routines". First you assign a button in FSUIPC to send a KeySend. Just assign a parameter of any previously unused number -- if this is your first, why not 1? In Wideclient.INI you assign KeySend01 to the keypress of your choice -- all the codes are clearly listed for you. Everything else depends upon how your voice thingy works. If it has the keyboard focus all the time, then the simple assignment of a keypress to the KeySend should work. If not, there are various alternatives, ranging fr om directing the keypress to a specific Window Class (which would involve some assistance from the author I suspect), or, more simply, making sure the program is actually loaded by Wideclient in the first place and just telling Wideclient which loaded program to send it to. There are a couple of variations which will only confuse you at this stage. All in all it is utterly and completely dependent on the target program. But all these things are covered in the WideFS documentation in more detail than I'm likely to be able to go into here. This is why documentation is produced in the first place. ;-) Regards Pete

Yes, you can do that, but it's a little complex to set it for keypresses. If your PTT is operating voice in Roger Wilco, or AVC, or Squawkbox 3, then simply assign the button to the PTT transmit on (when pressed) and off (when released). If you are using the latest FSUIPC and WideFS, the rest is taken care of for you. You don't need to use any special keypress. Regards, Pete

Ouch! Glad you sorted it. Thanks for letting me know! Regards, Pete

Agreed. In fact, in my opinion, the rendition of mist and fog was actually better in FS2000 than in either of its successors. Regards, Pete

One further note. I just checked, and when I said "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." in fact I was wrong -- the FSUIPC gust suppression does suppress wind variance as well. So all three influences can be suppressed in externally supplied weather, if you wish. Your report is most definitely sounding as if it is due to one of two things: either you have wind smoothing turned off, after all (as in the other reported case), or the downloaded ASV weather had some really weird values in it. More likely a combination of both. If you think neither to be the case still, send the files and I'll see what I can find -- but if it is a problem in FSUIPC I'm pretty sure it isn't new to 3.51. Regards, Pete

Phewthat's a relief. thanks for letting me know. One down one to go! ;-) BTW you should not need to reconfigure when merely replacing the FSUIPC.DLL file. I take great care to retain all the options in your existing INI file. But some folks automatically delete FSUIPC files when updating -- it isn't necessary. Only delete your old INI file if it is years ago when you last updated FSUIPC -- some of the defaults may have been changed or old parameters made obsolete. When updating simply copy the new DLL into the FS Modules folder. It will replace your previous one with no other changes needed. Regards, Pete

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