Pete Dowson

Oh, how odd -- but they use the Windows and 'Menu' keys? What is this 'Menu' key, please? I've not got one, at least not labelled as such. The Windows virtual keyname "VK_MENU" is actually the Alt key. I'm not sure if I can easily get hold of the Windows key -- I'm only processing normal Windows keyboard messages. I can check though. Doesn't it stop its use to get the Start stuff opened? [LATER] Okay. There are two "Windows" keys (LWIN and RWIN) and they are usable provided Shift or Control is pressed and held first. I could treat them both the same, as your "Win" key. I have another key, to the right of the right-hand Windows key, with a little menu drawn on it. Is that your "menu" key? If gives a Windows keycode of VK_APPS (0x5D), so I could use that. Is that the one you mean? If so, is it well known as the "menu" key? I must admit to never having even noticed it before, let alone pressed it! Regards, Pete

Can't you use assignments containing different combinations of Ctrl, Shift and Tab, with a normal key, only? Surely there are enough? Regards, Pete

Sorry, I have no idea, though the PFC one will be using separate throttle inputs for each engine whilst the simple single slider uses the generic all-engine throttle, akin to the 3 and 9 keys on the number pad. Have you asked Mr. Frolov (or is it Mr. Fanda?) about it? Possibly he intercepts and discards all attempts to assign individual throttles. You could test that theory by re-assigning your "standard slider throttle" to one of the specific engine throttle controls in FS (Options-Controls-Assignments). Or, possibly easier, map it to the 4 separate throttles in FSUIPC's Joystick options. Unfortunately, I really cannot keep abreast of all the different ways folks find to re-program FS in their aircraft. Sorry, no to both. Before this the only Dash 8 I'd heard of was the PSS one. Regards, Pete

There has been no change whatsoever in anything which pmRemote would use. It sounds like you have something else wrong. Best to check with PM Support. Also check the FSUIPC Log file to see if there are errors being reported. Maybe you have an improperly installed FS9.1 Update? Seems a lot of folks have. Check the list of changed FS modules in my FS9.1 announcement. Regards, Pete

Well, I was planning to release 3.41 this week if possible, mainly to deal with those mixed FS9.0 and FS9.1 systems folks have got themselves into and which are causing me too much support work otherwise. However, a few other things have come up and I am not so sure it will be this week now, but I hope so. However, I don't know if I can deal with this "turbulence as variance" thing quickly or reliably enough to fit that in for this release. I need to look at it and understand it first. I don't know how it is by-passing the wind direction smoothing part of the wind-smoothing routine, for instance. All I can say for now is that I will try to make time to look at it before release and if it looks easy and not dangerous I'll slip it in, but if it needs a lot more investigation and testing I will have to leave it to a later release, maybe 2-4 weeks off. Regards, Pete

Hmmm. Seems like you've found a deficiency in my smoothing :wink: -- the variance isn't subject to the smoothing and it sounds like that is what you are enjoying. I'll take a look at enabling the turbulence through variance again in a forthcoming release. Thanks, Pete

This is the one which converts wind turbulence (which didn't work anyway) into wind variance (changes in direction) which did. Both work in FS2004, which is why that facility was removed. That's a bug in FS2004 which unfortunately we now know won't be fixed till FS2006. However, it really isn't that common. It never affected me and it took me a long long time to reproduce it enough to convince Microsoft they had a problem! Well, FSUIPC fixes some things in FS2002 and some things differently in FS2004. It's user's choice I'm afraid. I can't fix everything. Regards, Pete

There won't be any at all unless you disable FSUIPC wind smoothing, assuming you have it enabled. The two facilities are mutually incompatible I'm afraid. No, there's no difference in any versions. It's all dependent on whether you want smoothing on or not. Is it? Which box is that, please? I'm confused now. I don't remember ever providing any "level of turbulence" box. there was a facility to convert FS's "variance" into "turbulence" with a settable strength, but that was because the wind turbulence didn't work. It does now, there's no point in converting it. Wind variance works as well, separately. You are talking about CLOUD turbulence, not WIND? Please, don't keep it a secret. What parameter was it? I will check. Honestly, I've not knowingly removed any facility still useful. If you are relying on one of the "random" turbulence facilities then, yes, it is supposed to vary. That wouldn't be anything to do with any parameter. Where is the weather coming from in the first place? FSUIPC cannot add these things to FS's own weather, only the weather from external weather programs, and I think most of those control the turbulence effects themselves. Please be a little more specific in each stage of your report, then I may understand it and be able to help. Regards, Pete

If FSUIPC doesn't see the vertical modes being switched on in the AP, as in some of these sophisticated aircraft which do their own thing, then this automatic option cannot work. One way would be to "park" your trim in a non-jitter zone so it doesn't feed any conflicting values -- axes only have an effect when their values change. Another way is by programming a key or button to disconnect/reconnect the axis manually, in FSUIPC -- more below. Ideally, of course, the panel itself should do this. I think the PMDG aircraft already do so, and also any Fly-by-Wire aircraft using FSUIPC to disconnect your axes from direct control. But the 767PIC predates this, and in any case it doesn't use FSUIPC. The offset is 310A and the bit for elevator trim is bit 5 (value 32 or 0x20). Program a button or key for "Offset Byte Togglebits" offset x310a, parameter 32. Or you can have one to disconnect it and another to reconnect it -- Offset Byte SetBits and Offset Byte ClrBits, in the drop-down lists in FSUIPC. Regards, Pete

The MAGDEC.BGL (in FS2004 it's in the Scenery\BASE folder) contains all the magnetic variations as 16-bit words (0x8000 = -180 to 0x7fff <= +180) in a 360 x 180 matrix, one value per "square" degree of Lon/Lat. So it is easy enough to update if you have a good source and are handy with VB or something. Naturally, the FS values, when released, are frozen to match the state of the FS Jepp database for the airport facilities data, and navaids. Normally I think that data is frozen about one year before release, so the FS2004 values would now be over two years old and the FS2002 values over four. Regards, Pete

The single lever Prop pitch calibration is on Page 2, along with the mixture and left and right brakes. In order to use Page 5, for all the separate engine controls, you EITHER need to select "map to 4 props" on page 2, or you need to ensure that you are assigning your levers to the individual engine controls in FS's own assignments first. Have you done one of these things? Are you following the step-by-step instructions? If not, try them. If you are, which step are you stumbling on? I cannot understand how you can go wrong? Please explain. Regards, Pete

If removing FSUIPC altogether like that has no effect then it isn't FSUIPC which has anything to do with the problem. Sounds like you have something else messed up somewhere. Sorry. Most likely causes of freezes are video card drivers, corrupted weather files, some add-ons, or probably any of many other FS file corruptions. Your best bet, if you've not too many add-ons installed yet, is to completely uninstall FS2004 and start again. Don't forget to remove the FS9.CFG file in your Document and Settings folder someplace and any saved flights in your "My Documents/Flight Simulator Files" folder. If that's the complete log, all that shows is that FS is hanging during or immediately after loading data for your startup file, the default one with the Cessna by the look of it. Regards, Pete

Okay. In investigating this track versus heading business I have found two oddities. One is the error in the RMA sentence, which I don't think would be related to track or heading -- it would simply be an invalid sentence and be discarded. The other is that there are times (most times I've tested so far) where the MAGNETIC track supplied to me from the GPS part of FS is correct, whilst the TRUE track supplied is wrong, and in some cases wildly so! Note that all the standard NMEA sentences use the TRUE track, whilst the AV400 format uses Magnetic. As well as fixing the RMA sentence formatting, I have now discarded the use of the GPS True track reading and only used the Magnetic one. To provide the True track for the NMEA sentences I adjust by the Magnetic Variation, which I already know. These changes are in version 2.57 of GPSout which I will release today. As it is such a small ZIP I attach it here, too. Regards, Pete GPSout.zip

Further to the above, please now see the message I have added to your "NMEA Track" thread.

Ah, that is nice to hear. I knew it could be done!! :D Thanks, Pete

IN is the value being read from the joystick, OUT is the result of your calibrations. Those are the two values shown on the extreme left. Neither are relevant here at all. You simply click the "set" buttons above the Min/Centre (twice)/Max slots when calibrating. Don't worry about the actual numbers, you should only be concerned about the lever positions. With the extremes there are of course two values -- but one is implied, it is any value less than (for reverse) or greater than (for takeoff) the value you 'set'. The setting of a value OTHER than the extremes gives you the "dead zone" at the extremes which guarantees you can always achieve full off aqnd max thrust. Always allow leeway at either extreme. With the centre values, here used for idle, you have to click the "set" above the values twice, de-limiting the zone in which you want idle to operate. Don't rely on the lever always giving the same output when it's at the detente! All this is clearly explained, step-by-step, in the FSUIPC user documentation. Why is it confusing you, please? Jitter, temperature variation, poor electrical contact on potentiometers, all sorts of things cause that. This is precisely why you should calibrate a zone around the detente, exactly as described in the documentation! If you do not use these facilities, for precise zone definitions, then you may as well not use FSUIPC to calibrate but simply rely on the Game Controllers and FS default settings! Regards, Pete

I have no home page. If you are referring to Enrico Schiratti's "Dowson" page, there are most certainly links there to both here and to the place where you can purchase FSUIPC or WideFS. Five days is rather a long time to leave it! It does say "Personal Registration Key will be Generated and Emailed within 24 hours" on the site. After that you should fill in a "trouble ticket" (I think that's what they call it) -- this is via either the "Customer Services" link at the top of every sales page, or the "Contact Us" in the "Information" lists on the left. When you get to the Customer Service page (which you can also get to via http://www.simmarket.com ands the link at the top of the page), I think the very first selection takes you to where you can report your problem. I think that such problems are usually either a difficulty over payment, or an incorrect email -- in the latter case things go astray, of course. I think I will make a "Sticky" thread about this! :wink: Regards, Pete

Ah, I have indevertently answered this in that other thread. Could you refer there, please, to avoid duplication? Thanks. [LATER] On further investigation I have found some oddities which I will report on in this thread -- see next message. Regards, Pete

Actually, if you have a dual monitor PC and one with enough capacity to drive FS and the GPS emulator, and you either have two COM ports spare, or a USB serial adapter or two, you can simply loop the cable back to the same PC and do all this on the one PC. I expect this would work best on an Intel P4 with hyperthreading, as it seems FS only uses one of the two "virtual processors". The RMA sentence is really a subset of RMC -- its data is completely duplicated. It is just missing the date and time. You shouldn't need both. Much of the data is also reproduced in GGA (full latitude and longitude), but it does supply the altitude as extra to the others. GPSout provides the TRACK in the GPRMA and GPRMC sentences, and both TRACK and Magnetic HEADING in the GPVTG sentence. The wind details are not supplied in any of the GPSout sentences, so I don't know how the emulator is deriving the heading from the track. That is most odd. GPSout calculates the track itself using wind values unless you are using FS2004 -- then it gets the track from the built in FS GPS, which is probably a little more accurate. Perhaps you can compare values there? One thing to note: in the RMA, RMC and VTG sentences, the Track is degrees TRUE *not* magnetic, as per NMEA specification. The magnetic variation is also given. The difference in the AV400 format is that the Track is degrees Magnetic. Perhaps your observations are only a mix-up between degrees magnetic and true? If you were testing with the default FS2004 startup, i.e. at Seattle, the variation there is about 20 degrees. WARNING! In putting this together, I have just noticed that in the current version of GPSout the RMA sentence is, in fact, wrong -- it is undoubtedly being ignored in any case. I will fix this and release an update this weekend. (And, no, it isn't wrong in that it gives heading instead of track, it is simply formatted wrongly altogether). Meanwhile, take RMA out of the equation please. Regards, Pete

Designed to prevent the arming of the spoilers except by mouse? How perverse. Do they not want anyone to arm the spoilers at all, and simply failed to ignore the mouse activation? So you, yourself, don't bother to arm the spoilers, or are happy to use the mouse? Okay, thanks for the help. Regards, Pete

No, that should be okay. Although really, of course, I'd prefer that you insist that folks keep their FSUIPC up to date! (Makes support much easier! :wink: ). You could work that out from the code, as you have looked at it in any case to do the above changes. The FSUIPC_Read and _Write calls are entirely dealt with in your program, not in FSUIPC. You'd only get a FALSE return if you hadn't got a correct Open to start with, or you run out of space in the memory you provided for the transfer (or, in the case of the external library, the maximum allowed -- around 30k I think. Yes, you could do -- but the results you do get will be okay for the Reads which worked, of course. Really such errors should be found during testing, and rectified before release. Once the program is working they should not occur. I agree that the program should be bullet-proof though and the cost in extra code is minimal to leave checks in. Regards, Pete

You may need to design this for a specific aircraft, because the extent of the trim available is probably aircraft-dependent. If you want to use it with a variety you'll need to measure that value (in radians) for those and select the maximum. The it is merely a matter of simple arithmentic to scale the value. For example, if the trim varies from -0.2 to +0.2 radians and you want a range from 0 (for -ve extreme) via 128 (centre) to 255 (+ve extreme) you would need to do this: ScaledValue = (RadiansValue + 0.2) * 255 / 0.4 The "+0.2" is to get the -ve maximum to your zero, giving a Radians range of 0.0 to +0.4. Then the * 255 / 0.4 merely scales that to the range 0-255. As for the rest, I'm sorry but you need someone who knows Visual Basic. I have no idea why you are using this "currency" type when I am pretty sure VB supports double floating point numbers as a type on its own. Isn't "currency" a way of faking 64-bit FIXED POINT numbers, like the latitude/longitude, not floating point doubles like this? Are you perhaps getting confised between totally different 64 bit representations? I expect someone who knows VB will jump in. Regards, Pete

Well, I'm not sure how you are coming to that conclusion from what's been said here. However, I've just switched on my FS PC and loaded up the PMDG 700 (I don't normally use any panels at all), and you are correct in that none of the controls which should arm the spoilers will do so. Worse, it even defeats direct FSUIPC offset writes to arm the spoilers -- I use the PFC Jetliner console with a spoiler lever, and this won't arm them either. I feel sure this must be an oversight by the designers. A bug even. Have you actually tried to get a solution in the PMDG forum at all? I would expect there to be a higher proportion of PMDG flyers there than here. And either way it is certainly worth reporting to PMDG themselves as a probable bug, or certainly a serious omission. Why sorry? Key2Mouse is by Luciano Napolitano, author also of WidevieW, see http://www.wideview.it/key2mouse.htm. Regards, Pete

Well, it does help me. Thank you David. Regards, Pete

Maybe, but that is not a button/key control. Test the keystroke/control only in the air. You'd never arm the spoiler when on the ground in any case as they are triggered by a switch on the undercarriage and during takeoff roll they could deploy accidentally and cause a nasty incident. I think those aircraft which do deploy spoilers on RTO do so without any arming needed -- and, actually, I think the real 737NG deploys them without ariming on touchdown (maybe when reverse is armed, I don't recall offhand) -- perhaps the PMDG cockpit is emulating that correctly? Have you tried simply landing without arming and seeing if the spoilers are correctly deployed? Test in the air, as I said. But if this is only with the PMDG aircraft, it is likely they have taken over the operation of the spoiler and perhaps made it operate as in the real aircraft. Have you tried using it as in the real aircraft, to see? Does the PMDG package offer its own spoler controls, perhaps? Because mouse actions operate directly on the gauge which then uses a different input to the simulation engine. It doesn't emulate either keystroke or button controls, which are processed in a different way. Why are you so desperate to arm spoilers on the ground? Regards, Pete