Pete Dowson

I just checked -- the 4 or 6 decimal place option doesn't apply to the AV400 format in any case. That's fixed as defined in the AV400 spec (more below). But most all of the output must be right as you said "Track is good ,speed is good,alt is good". I can't see how the device can get those correct yet screw up the latitude and longitude. It doesn't make sense. If you had anything wrong with the connection data none of the values would be correct. Well, the actual protocol I implemented is called "Series 400 Aviation Format", so maybe there are other "Series XXX" versions. Isn't anything mentioned in your GPS documentation? If you can get details of whatever protocol is used, and it isn't too far removed from what I do already, I can consider adding it to GPSout. Maybe you can get stuff from Garmin? Regards, Pete

Where are you looking at the Needle values? You cannot necessarily judge it by the on-screen monitor display facility as I think that will be affected by the FS display logic (though if you are using the same for the altitude I suppose that's discounted already). FSUIPC's Monitor operates up to 4 times the frame rate, so maybe logging to the Log file will work. FSInterrogate's update rate isn't all that fast, but faster than 500 mSecs by default I think. However, if any of the methods "look" like as much as half a second then it seems that it must be pretty sssslllloooowwww. I could send a test version of FSUIPC which updates those locations as much as 4 times the frame rate (varies) but I don't know how you'd monitor it fast enough to check, and it would be an even bigger waste of time if indeed FS is limiting them somehow. If FS is limiting the update for these values it is probably a performance thing, based on the assumption that the only thing which needs them is the gauge and its resolution wouldn't support a faster rate in any case. What exactly are you needing this for in any case, BTW? Are you trying to control landings using the GS/LOC? Wouldn't simply maintaining the correct V/S and Heading, once engaged, be better if so? The values for these (GS angle, correct and accurate heading) are available. Regards Pete

If the FS2004 install is on the same PC (without a Windows re-install), then you only need to copy the FSUIPC.KEY file into the Modules folder. Otherwise you need to re-register -- but you MUST use exactly the same details as before. The software does NOT change like that, and purchased keys have no expiry date. But the Key is intricately related to your registered name and email. Every single character of every part of those three things must be correct. If they are it will work, if not it will fail. In almost 100% of cases the problem has been that folks use different names for themselves at different times, or change email addresses. The KEY only works with the ones you registered. (The only exceptions were some names with accented characters in the very first release two years ago, quickly corrected, and keys which have since been blocked through use of illegal generators, lack of payment, or breaking of license rules such as openly publishing details or sharing them with others). If you believe you have entered everything correctly and still have problems, please put together all the details, including if possible the original notifying email you received with the Key, ZIP them up and send them to me at petedowson@btconnect.com. Do NOT publish any details here. Regards, Pete

I have no idea what FS's update rate for these things are. I said that I'd changed FSUIPC's priority, for those only, to make them update on every frame. In other words I read the values and place them in those offsets on every frame. Whether FS changes them on every frame I've no idea. Possibly, or equally possible, the resolution is still quite limited so you don't see small enough changes. If they definitely are only changing every 500 mSecs then I can put them on my lowest priority -- a 440 mSec update rate I think -- along with the FS98 equivalents at 0C48 etc (I think those are on a 110 or 165 mSec rate at present. Apart from my frame-related rates, others are all multiples of timer ticks which, at 18.2 Hz, are 55 mSecs apart). I don't like to waste time unnecessarily! ;-) Regards, Pete

Try setting the PosTo6Decimal to "No". Maybe the excess digits are mucking it up. I really can't think of anything else it might be. Certainly nothing in your FS scenery add-ons. Regards, Pete

Well I know that the 737NG configuration for pmSystems is good -- I use it. Actually I use one developed from the default by Thomas Richter. You can find it attached to some of his messages in the PM webboard/newsgroup. Certainly the Cutout operates okay, for example. To check things with pmSystems you need to view the switches on the graphic whilst operating your own hardware switches. Well, pmSystems is very flexible but it does take some work. Your best bet to get help is to post on the PM webboard rather than here. There's a dedicated pmSystems section with some very knowledgeable and capable folks in attendance, like Andras Kozma and Thomas Richter. Regards, Pete

The 56xx range of offsets is used by pmSystems. Do you use/own pmSystems? If not then you need to use the FS switches for these, as listed in FSUIPC's offsets. In FS "CutOff" is actually dealt with by the mixture control (full rich = start, full lean = cutoff). For any FSUIPC offsets operated by your hardware you can Monitor them in FSUIPC's Monitor facilities, as documented. See the Logging tab in the Options screen, right-hand-side. This is a good way to check that your hardware is doing the right thing. After that, if it doesn't do what you expect you have to investigate the target software, in the 56xx case this being pmSystems. You'll find documentation for both FSUIPC FS offsets and the standard PM offsets on the http://www.promagenta.com Documentation page. But for pmSystems (which is entirely user configurable, INCLUDING the offsets) you'd need to look into the SYSVAR.TXT file supplied with the package. Regards Pete

Oh, right. I'd never have guessed it would be a DX problem. Nothing of mine uses DX so it's an area I'm rather ignorant of I'm afraid. Glad you got it sorted. Regards, Pete

What is? Sorry you've lost me now. I've no idea. Sorry. This sort of question is best put to the PM support folks, surely? Well, they've adjusted exactly enough on both my old B&W 5" monitor with the PFC CDU panel, and the twin colour 5" TFT ones built into the PFC cockpit. I think both the OpenGL and the GDI displays are fully adjustable in all sorts of ways. The methods aren't intuitive unfortunately, and don't ask me to explain them. But they do the job. I'm sure PM support will be able to help you. Regards Pete

Sorry, I don't understand. What is "trc# 1047"? What are you really meaning by "PM codes" as opposed to "FSUIPC codes". I'm afraid you've lost me completely. Pete

Not that I know of. Sorry. Pete

I'm not the person to ask as I don't like the OpenGL CDU display, even though it is more "realistic". I feel sorry for real Boeing users having to put up with it. I like the original PM CDU default "truetype" display, or whatever it was. I'm sure Boeing would too if they could get it! ;-) Regards, Pete

That's great! Well done! I shall make a note of that and maybe program some here too (but not WX mode -- see below). Thanks! I think there's some provision, deep in the PM CDU someplace. But I think it works differently -- doesn't the CDU program have to be run on the same PC as SA_WXR for that? I never got it working, but I don't run SA_WXR in either the PFD or CDU PCs. I switch the WX display on the ND using the WXR switch on the EFIS. i.e. from the PM side of things. I think the WX file stays in the ND folder whatever. The WX on/off for SA_WXR only controls its own display I think, except that obviously you need it ON to switch it ON or OFF in PM. Sorry, I don't. A question for the PM webboard perhaps? Regards, Pete

In at least the first two cases that is most certainly true. SB3 is complaining about the Multiplayer connection, which is outside of WideFS/FSUIPC altogether. ASV is merely asking for the full path to your FS installation so that it can manipulate the cloud graphics, something added in ASV from previous releases. it will be something like \\\... You probably need to make it a specific shared folder on the FS PC, and maybe even a mapped drive on the ASV PC. I'm pretty sure the ASV documentation goes into all this -- if not check with their support forum. As for FlightKeeper, I don't know, but I suspect it needs to scan all your scenery files in order to build a correct matching database. It may have to be run initially on the FS PC, at least for speed in doing this, then have the database copied over. I know I had to do this with TrafficBoard. The connection through WideFS looks okay from your logs, though short-lived because none of the programs actually ran for long because of the other connection issues. Yes, but do check the documentation for those programs more thoroughly first. I think these issues are normally covered in some detail. Regards, Pete

Thanks Nico. That's useful. It's a pity the same cannot be done with the PMDG series of aircraft. What about the PSS ones? Are they open to cockpit developments do you know? Regards, Pete

FSUIPC provides an interface to Flight Simulator. If Flight Simulator provides the facilities you are after, then you should certainly be able to access them in FSUIPC. However, FS itself does not support any special means of starting engines on any specific aircraft and, in fact, it doesn't even come with an Airbus model built in. For FS engine starting please refer to offsets 0892, 092A, 09C2 and 0A5A. Once you have turned on the power (battery), FS engine starting for jets consists of turning a starter switch, and holding it, and introducing fuel (via the same control as the "mixture" on props) at the appropriate time. Specific add-on aircraft may have more sophisticated, more accurate, ways of doing it, and these facilities may or may not overlap with the inbuilt FS facilities. Whether or not you can operate them through FSUIPC then depends entirely upon how the authors have implemented them. If you are using Project Magenta then quite sophisticated subsystems can be correctly implemented through pmSystems, and all of Project Magenta is programmable via FSUIPC and documented fully for this purpose. Regards, Pete

WideFS is quite unconnected to Multiplayer. I really don't know anything at all about multiplayer -- you need SB support on that. SB3 uses FSUIPC/WideFS for getting the aircraft position and setting stuff like weather. It uses Multiplayer to provide the images of other flyer's aircraft. Again this is nothing to do with WideFS, which doesn't connect folders. I think you need to tell ASV where FS is so it can manipulate the cloud textures. This is to do with the Cloud facilities now added to this weather program. I think the documentation covers it well. And what does it say? Possibly it needs access to the FS scenery files in order to build its database. Nothing you've said or shown indicates anything wrong with the WideFS connection, quite the contrary in fact. All the programs you refer to need other channels to FS's files as well as the FSUIPC/WideFS interface. I think you need to study their documentation a little more, please. Regards, Pete

Hi again, I found the information you must be referring to towards the end of the SA_WXR User's Manual. Unfortunately I don't really understand it either. For offset 6D00 he's provided two modes -- a switch mode where a bit=1 for switch set, =0 for clear, and a "toggle" mode, where I assume you have to change the bit to change the switch. The problem with the toggle mode, if indeed he does mean you have to change the bit rather than just write to it, is that it appears that to change the Mode you have to write 0 to bit 7 and 1 to bit 1 as well as, at the same time, toggling changing bit 0. Without writing a program to do this is isn't really possible -- certainly not with one control anyway. Looking at the "switch" mode, it seems you have to set bit 7 to 1 (easy enough), but not change any of the bits you don't want to change the settings of. For the mode this makes it difficult (impossible) to do in one control yet again, because you need the lower two bits set 00 for OFF (i.e. CLEARING, not SETTING bits), 01 for WX and 10 for WX+T. Again, in every case you have to set some and clear others. Without doing a simple write for the BYTE at 6D00 it cannot be done in one control. To write it in one byte you'd also have to write the correct bits for the Range and your OFP and GCS switches. Maybe I'm misunderstanding all this, but to my reading it looks as if the interface is designed for programmers to use in interfacing a separate control program to SA_WXR. I cannot see any sure way of doing it with simple FSUIPC key or button programming. You could TRY sending two controls per key or button press. That would mean editing the FSUIPC.INI file -- or for buttons you could, I suppose, send one on the press and another on the release and still program it in the dialogue. Whether this would work properly though, I really don't know. It seems unlikely to work consistently. To try this the pairs needed would be: To set OFF: ---- Offset Byte Setbits, offset x6D00, param x80 ---- Offset Byte ClearBits, offset x6D00, param x03 To set WX: ---- Offset Byte Setbits, offset x6D00, param x81 ---- Offset Byte ClearBits, offset x6D00, param x02 To set WX+T (aha! One control only! ;-)): ---- Offset Byte Setbits, offset x6D00, param x83 To increment tilt ---- Offset Byte Setbits, offset x6D00, param x80 ---- Offset SByte Increment, offset x6D01, param x01/x7f To decrement tilt ---- Offset Byte Setbits, offset x6D00, param x80 ---- Offset SByte Decrement, offset x6D01, param x01/x80 Without further help from Florian I'm afraid this is about all I can suggest. As I say, I have doubts that these sequences will work, because I don't know what the program will do "between" seeing each change. Maybe sometimes it will work (because it will see them as one change), whilst at other times it won't. I recommend you ask the author, Florian Praxmarer for more assistance in this. Perhaps he can be persuaded to give working examples in his document. Regards Pete

I don't use those options at all. Can you be more explicit about what you want to do with what offsets please? Regards Pete

Yes, it is almost impossible. Try running FS in Windowed mode instead, you can make it work then. Otherwise you have to keep trying all sorts of horrible repainting tricks involving intercepting loads of messages. It really sucks and gets extremely convoluted. Ugh. It worked with FS2002 (but even then it was messy). The problem with FS2004 is the new way the DirectX does the graphics. I once asked some FS team guys how to get around it and they pretty much said "don't, it isn't possible"duh! :-( Pete

Yes, and because it is allowing the higher values through and only THEN changing them, there is absolutely no way you can fix that. The gauge needs to be written so that it traps the joystick inupt and modifies it before FS sees it. Yes, but it cannot change dynamically. Your gauge is trying to do that. You can't do both in any case. It would be best to write the gauge correctly in the first place. I cannot see any other way. It is exactly as you explained before, but it still makes little sense to recalibrate any axis suddenly in mid-flight just because of a flaps change. You would have a sudden change of surface positions as a result, as I explained, and probably lose control. If your gauge is meant to do this limiting slowly, gradually, then that is fine, but it needs to do it BEFORE FS sees it, not after, otherwise you are bound to get your flutter. In my opinion you would be much better off simply using one of the flattened-centre FSUIPC calibration slopes, so mostly you have less severe effects for most of the movement but are still able to reach the extrmes when needed. It is exactly for the sort of control variations you are describing that these facilities were added. Regards, Pete

Well, no one from FS HotSeat has talked to me, but I have been part of all the Radar Contact beta teams for years, albeit not really as a fully active tester. There are two ways to get the needed AI data -- in bulk through the original TCAS data area I devised, or one-by-one for specific AI aircraft through a request-and-response system. The former is suited to TCAS displays, and anything needing lots of data for lots of AI at the same time. It is they which need the option set appropriate to the needs, with the default Airline+flight number being normal. For ATC interaction with many AI aircraft, RC also falls into this category. RCV4 does use the individual request method when it is identifying the make/model of aircraft in front of you so that it can give appropriate instructions as in "after the 737" and so on, or in notifying nearby aircraft types when airborne. As far as I know FSHotSeat (which is almost not at all I'm afraid), I think it mainly needs the latter simply so that it can play appropriate sound effects. No doubt you will corect me if this is wrong. The problem is that FSHotSeat was probably written in the days before the individual AI aircraft request method was provided, and the author did not come to me and explain what he wanted to do so that I could meet his needs (as I did with RCV4). The answer to the problem now, apart from not using both together, would be for a revised FSHotSeat to use the individual request method for its AI data requests. I am sorry, but I hope you now see that there is really no solution I can implement in FSUIPC. But there is a solution, and it is in FSHotSeat's author's hands. Regards, Pete

Ok -- the raw values are changing rather more frequently than the 256-graduations which the variables you use indicate. In the updated FSUIPC attached I've provided the values in 32-bit floating point format (float or FLOAT32) as follows: offset size meaning 2AAC 4 VOR1 Localiser needle value in 32-bit floating point format 2AB0 4 VOR1 Glideslope needle value in 32-bit floating point format 2AB4 4 VOR2 Localiser needle value in 32-bit floating point format 2AB8 4 VOR2 Glideslope needle value in 32-bit floating point format I'm also updating these more frequently (at least every frame) than the FS98-compatible values. This applies to FS2002 (untested) and FS2004 (tested ok), but nothing before these. Let me know if this does the job you want. Regards, Pete FSUIPC3509test.zip

Yes, the resolution of even the best gauges presumably never needed more than 256 steps. Hmm. I don't know if the raw data I'm using to populate those is any more accurate. Just being in floating point format doesn't mean more accuracy -- there are lots of cases in FS where floating point resolution is is just as low as that shown in the old FS98-compatible ways. I'll check the raw values for you and let you know. Regards, Pete

I don't quite understand. Do you mean that the gauge is letting the joystick values through to FS, and only then changing them? If so, then, yes, I would imagine that would give a very unstable effect. Well, no, this is not currently possible. You can have separate calibrations for different aircraft, but not for different settings on a single aircraft, dynamically changed. Actually, I don't really like the thought of that in any case -- you would have to be sure to have the elevator and aileron more or less centred when changing from no flaps to flaps or vice vera, or face a severe risk of losing control because of the sudden drastic change in the control surface positions. Additionally, if FSUIPC were limiting the values through a different calibration, what would your special gauges be doing? Are they reading the joystick axis at source? It sounds unlikely, as if they were they could modify the input to FS so that you wouldn't get the fluttering in the first place. If they are only monitoring the resulting surface positions then FSUIPC's calibrations would have already occurred, so the gauges' actions would double the effect. No. It seems to be that the only solution is for the gauges to intercept the axis controls en route to FS, modify them as needed, then pass them on. Then you'd not get the fluttering. If using FSUIPC calibration you'd then need to be sure to calibrate with flaps up. Maybe I'm misunderstanding you in the first place. If so, apologies. I'm not even sure why you'd want any of this in any case, but I assume it is something to do with the incorrect behaviour of a particular aircraft? With many airliners the main effect of flaps on control sensitivity applies to stabiliser/elevator trim. For instance, on the 737 the trim should be operating twice as fast when any flaps are down -- you can actually see the trim wheels spinning faster when electric trim or autopilot trim is performed. Regards, Pete