Pete Dowson

I don't think there is one. At least I've never found it. The gauge seems to be mouse driven only. Just badly written. Maybe there's a third party one around (probably in a third party panel) that obeys the controlled selection and hasn't got it purely internally coded as that one seems to. The one in the Cessna's main panel obeys the "TOGGLE DME" control, like the radio stack, but I don't see the "DME", "DME1 TOGGLE" or "DME2 TOGGLE" controls doing anything in either. Regards, Pete

With crosswinds too, please. Well, I might detect FS2004 and read the FS GPS "track" value if possible, as I'm concerned that variable winds and turbukence will make a right mess of it! Tomorrow. Regards, Pete

With crosswinds too, please. Well, I might detect FS2004 and read the FS GPS "track" value if possible, as I'm concerned that variable winds and turbukence will make a right mess of it! Tomorrow. Regards, Pete

It cannot see commands given on the keyboard. they are not actioned by FS sending a message with the control numbers I recognise. They operate through some keyboard table some place. Whilst I could intercept keypresses I do not have access to the table so I don't know which should do what. besides, I've never has a need to do it. In the case of Gauges it is different. I do see "trigger_key_events", so if the gauge uses one of the FS controls I know, I will deal with it (if asked to, of course). I expect all that is happening is that the regularly-polled input from the axis is overriding the key press. Or maybe it is more serious, but I couldn't say from experiments I'm afraid. What "non-proportional" brake commands are you using from a gauge? If you used the AXIS_LEFT_BRAKE_SET and AXIS_RIGHT_BRAKE_SET controls (the ones used by FS2002 and FS2004 for brake axes), then I should think these would be okay. You could experiment with those by assignment with different parameter values in FSUIPC's Key or Buttons pages. No, not at all. It changes the braking pressure directly, inside SIM1.SIM or SIM1.DLL, where it actually has effect. It is not sending any controls to anything. It is direct maniplation. It was the only way on FS2000 -- there were no controls whatsoever providing any proportional effect, though internally the simulation did have the implementation of braking pressure, as you could see by its gradual reduction on release, or increased effect when "pumped". Since when using FSUIPC for proportional braking the axes aren't really connected to FS, I assume it won't occur, but I've not tried it. Not sure why. Isn't it for the same reason? Q1. Yes as far as your (1) is concerned, and I don't see that (3) is different. Q2. Well, not really, you would expect folks to either use axes or use keypad. If I were writing a simulator I'd choose axes over keypad, if I knew it was operable. I'm not sure how you'd deal with conflicts between them. This is one way I suppose. Q3. I can't deal with FS keyboard controls, and I've no idea what you are doing inside your Gauge. But if you wanted you could make your gauge control brakes via FSUIPC offsets instead of FS controls. Then it shouldn't interfere with any other FS functions. Well, I did apologise, and as I explained, I use it without thinking as I have done for 40 years or more. It is like any habit, difficult to break. I suppose if I said "+ve" you'd recognise the "+" as meaning positive, no? The problem is that the ASCII negative (-) is too short and used as a hyphen. I really cannot promise never to use it again just in case my recipient isn't so good at English, but I do apologise. I don't see what else I can do. And your English seemed so good! :) Maybe if your English was bad I'd have spelled everything out and used easier words in any case. Sorry again. :? Pete

Okay. If it is permanent fixed to magnetic, I'll change to that. Odd. I'll try to simulate something here. It's a bit awkward not having a device, I may have to write a little program to display things. I'm using the "ambient wind" value, which will change as you fly, especially if you have variable winds or turbulence set. But otherwise it shouldn't, as the same steady wind will be making me do the same calculations over and over. Strange. I'll see what I can find. Well, it's a lot more programming -- currently it's pretty much a single line of code to format the data I already have (for NMEA sentences) into the Aviation format. In FS2004 I can get the actual Track value your FS GPS displays. I didn't really want to make GPSout FS-version dependent, but I certainly could use the value to find out what's going on. Okay. Since I'm rather tied up today, I may send you a version which just provides Magnetic instead of True, and let you try that and report. If I have to mess with Track I'll look at that tomorrow. Okay? Pete

No. Use FS assignments to configure your separate throttles for each engine, then use FSUIPC's Joysticks section to calibrate the throttles with a centre (or more usually off-centre) position for Idle. Allow enough "dead space" for idle (and preferably notch it on your quadrant). Reverse will operate when you pul back further. In general allow about 20% of the movement for the reverse section -- the reverse thrust component varies frpm aircraft to aircraft, but is generally up to 25% of the full thrust amount. Regards, Pete

I am trying to compute Track, I'm not providing Heading. To do this I'm using the ambient wind values. I already do this for (for instance) FliteMap, and it seems to get the right values. Are you saying this isn't working in this format? It's the same Track figure as sent to FliteMap and others. The "HDG on screen" on the aircraft instruments is Magnetic, so you were facing Magnetic North, right, not True North (as you would be, for instance, in slew mode after pressing Space)? The MagVar in Seattle is, what, 20 East? Right? So 360 MAG = 20 TRUE. So the value of 20 shown on your GPS is correct if it is supposed to be showing TRUE rather than MAG. On my Garmin this is a user option -- many folks use TRUE (I do) because it helps with Maps -- usually Grid lines or somesuch are aligned with true north, NOT magnetic. Before I do any changes here you need to check things like that. You can't just assume them. But please also check it again with winds. It should give correct track too, maybe not accurately (the only real accurate way is to compute from successive coordinates, whch is what a GPS does). Sorry, you'll need to be MUCH more explicit there. When you say "offset slightly" what do you mean? What is "slightly". I am sending the position FS uses to 1/100th of a minute accuracy. That's all the protocol allows. I've no idea what you mean about confusion. It gets sent explicit Latitudes and Longitudes. there's nothing in those which will be modified by track, groundspeed or magnetic variation. Pete

No, no. That wasn't the problem. It wasn't anything to do with the attachment. The message went into my "OutBox" and stayed there, never moving to "Sent". When checking this I found TWO other messages, to the same person, still in the OutBox, one dating from a week ago! The second message was an answer to almost a repeat of the first, presumably because the author never got the reply. Those two mesages are STILL there, but the one to you has gone. I don't know what is going on. I've put some queries out to the Simflight operators, but I think they are all at Miguel and Andrea's wedding today! :D Ahthere's lucky, eh? :) The main thing I need you to check is the Track degrees. I've assume degrees TRUE, but they may need to be MAGNETIC. The doc doesn't say. Please try it in a region of large MagVar (eg. Seattle E 20 degrees MagVar) and let me know. Regards, Pete

Tuomas, please email me at petedowson@btconnect.com. I have a test version of GPSout for you to try, with "Series 400 Aviation" format support, as best as I understand it at present. I tried to send it via the private mail service here, to no avail I'm afraid -- I'm getting some messages stuck in my "OutBox" and not getting sent. I've no idea why. I've asked Admin here but not got a reply yet. Regards, Pete

Check with Enrico Schiratti at Project Magenta. He is in charge of Keys for PM. I think he provides time-limited Keys for demos, but I am not sure, you'll need to ask. Regards, Pete

Thanks for solving it without me! :D I will consider adding a check for this into the next version of FSUIPC. Regards, Pete

Goodthanks for letting me know! Regards, Pete

There is really nothing in any of the FS control mechanisms which will do this sort of thing. They are completely ignorant of altitude. Are you sure what you are seeing is not simple over-control due to poor responsiveness? If so then it is the performance of FS near ground which is the problem. Any slowness in responses to inputs can look like over-sensitivity because to tend to over-control when you see that your alterations appear to have no effect. If this is the problem, then I think your only recourse is a faster PC or reduction in some of FS's settings. Climbing away from the performance problems of ground and airport details. Regards, Pete

All the FS controls in CONTROLS.DLL are listed in both numeric and name order in my controls documents, on http://www.schiratti.com/dowson. There's one there for FS2004. That's the same list accessible for Key or Button assignment in FSUIPC's Key and Button assignment pages. "-ve" = negative. Sorry, I thought it was a standard abbreviation. I've been using it since I was a tot! Regards, Pete

Okay. Thanks for letting me know. Good luck! Regards, Pete

I think those values should be -16383 to +16383, but 16000 is close enough I suspect :D There are two sets of Throttle axis controls, one running 0 to 16383, and ones running -16383 to +16383. Both have idle at "0" but the ones with -ve ranges provide reverse thrust too -- these are made use of in the separate throttle assignments in FSUIPC. No problem! Glad you got it sorted. Regards, Pete

Apart from "type", what other measures? There was in FS2002, but you said you were using FS2004. It runs here without FSUIPC, but by all means install it as a test. Let me know. There's a serial port monitor, I'm sure, on http://www.systeminternals.com. Try that and let me know. Regards, Pete

Try using hyperterminal or some proper comms program then. It is absolutely certain that GPSout will be sending some data, whether is looks like stuff that the "type" command can accept is another thing. Why not try the actual program you want to use? There's a serial port monitor program at http://www.systeminternals.com, I think. If you seriously want to dig, use that. I don't really know what you are trying to accomplish. Pete

Standard NMEA settings - 8-bit, no parity, 1 stop bit. (All speeds have only one stop bit in any case -- 2 were used for 110 baud, I think, and there's 1.5 for ancient teletype mode). I don't know what you are using to check that there's no output, but if the program you are using isn't set up correctly it may not recognise the data. Otherwise the connecting cable isn't correct. Regards, Pete

The actual braking value should then decrease slowly to zero. Do you wait, or are you saying it never does? What are you actually reading? You can do, but I'd rather check the values directly, it is easier for me. I need to know what you are reading and what you think is wrong with it. petedowson@btconnect.com, but I may not get time to look at it. If I have the information instead I can do some quick checks, see what is going on. Please let's get this straight -- you originally said it fails when the user calibrates his toe brakes in FSUIPC, not just when he installs and registers FSUIPC. Those are two very different things. If you still really only mean when the user calibrates toe brakes in FSUIPC, then didn't my explanation of the difference help? You seem to have ignored it? Regards, Pete

That's an old S-Combo bug, fixed "years" ago! Please check with S-Combo support, or find a later version or fix. It sounds like you found an old copy. Regards, Pete

I never noticed that, but then I never have the PFC sounds enabled in any case. I'll try it here. If it works on FS2002 but not on FS9 it is probably because the code in the PFC driver cannot find the correct routines in FS9 to produce the sound -- it doesn't play them itself, it asks FS to. I know I got this working originally in FS9, but I may not have re-tested it in the final FS9 user release. Sorry. I was very busy. I'll check it and if necessary fix it for the next PFC.DLL release. Regards, Pete

Even when sending zero to the brake axis? FSUIPC's implementation of the toe brakes dates from FS2000 when FS included no brake axis controls. It operates directly on the braking values in the simulation engine. No, the Parking Brake controls are not touched at all by FSUIPC. There is no "scheduled" nature. However, because FSUIPC is setting the braking directly, when the brakes are released it has to control the gradual reduction in braking pressure itself rather than let FS do it. Normally when you apply the brake then release it, ot does NOT release braking to zero immediately, it is performed over time. It should be an exponential reduction, but I think it is actually linear. Anyway, you can see it happening if you watch the brake application values through FSInterrogate. FSUIPC emulates this by direct interaction with SIM1. Perhaps you are toggling the Parking Brake before the braking reduction has completed, and so your zero is being overridden. Try a few seconds delay. I really don't know about such a problem, as I have never come across it. Can you explain how I can observe it? How are you reading this brake pressure and how long do you wait? Regards, Pete

In FS2004 I get offset 0x02A0 (MagVar) reading 0xFF27 at EDDF. This is the same as decimal -214, which is -1.192 degrees. So, yes, you are reading the right value, pretty close anyway. I am really not able to debug whole code segments for you. But I just realised I gave you wrong information last time. This comes from perusing commentless code written two years ago! Sorry. The "distance" I am using is NOT the distance! I don't use the distance to calculate the bearing. The thing I thought was the distance is merely a value representing the difference between Longitudes, but corrected for Latitude. In other words, my comment in what I gave you: //dDst = computed distance "in radians (i.e. nms * PI / (180 * 60))" is WRONG! dDst is dDst = cos(PI * (fabs(dMyLat+pt->lat))/360.0)*(pt->lon-dMyLon); which isn't even Radians, but Degrees still. It uses the cosine of the average of the two latitudes to "correct" the difference in Longitudes, for the "narrowing" effect as you progress nearer the poles. This would go horribly wrong very near the poles, but is adequate for my purposes when in normal latitudes. Let's change the name to "dLonDiff". Then is is used in your dHdg formula but in DEGREES not Radians, thus: dHdg = (dMyLat == dAiLat) ? 90.0 : (180.0 * atan(fabs(dLonDiff/(dAiLat-dMyLat))) / PI); This is simple trig on the triangle. The rest of the corrections for quadrants is the same. Sorry to have misled you before. I was trying to "convert" my messy code into something presentable, and obviously I failed to understand it even myself! :oops: Note that my methods are most definitely aproximate. They make lots of assumptions. I am using plane trigonometry and assuming this matters little over the 40-80 mile range of the AI 'targets'. If you want pin-point accuracy you will have to look up the proper spherical trig equations. If you need it to work properly at high latitudes you need to look up the proper spherical trig equations. Apologies again. Regards, Pete

Can they be matched by different positioning of the 3 and 4 levers? If so it sounds like the pots are different or thee's some electrical problem. Maybe you can offset the Elite calibration to deal with it? If the axes are being fed to FS through normal axis input controls, then you could try using FSUIPC's calibration, but I think Elite do their own thing, don't they, and write direct to the throttle values? If not, then the FS "null zone" setting might be useful, differentially, on either 1+2 or 3+4 to get them lined up. >> e.g. Values in calibration page: all 50. Epr: E1 and E2 - 1.22, E3 and E4 - 1.27. << So try offsetting the calibration to get the same results. Of course it may not be a linear difference, in which case you are a bit stuck. There's nothing I know of in FS which would traet the different engines and axes differently, so it must be something in either the hardware or more likely the Elite driver. That's a shame asa they are the only folks likely to know what they are doing. I'd press them harder about it if I were you. Regards, Pete