Pete Dowson

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

The parameters for the C library functions sin() and cos() have to be in radians, yes. The result of the acos() will be in radians. Best do dMyLat * PI / 180.0 The magvar from FSUIPC offset 0x2A0 is 16-bit (short int), not 32-bit. And, yes, you have to convert it as it is in FS units. But do NOT use "(360/65536)" as that will give you 0! Use double dMagVarDegrees = (sMagVar * 360.0) / 65536.0 Always multiply before division if you want more accuracy, and always remember literal numbers are taken as integers by default unless you use ".0". Convert it to whatever you need. I convert it from radians to degres, then adjust it for Mag Var -- please look at my code again. I gave you the code I use. Sorry, I cannot really be more explicit. You will need to do your own debugging. Regards, Pete

I've never heard of a problem where WideServer doesn't produce at least the start of a log. But is sounds like one of two things. Either there are multiple copies of one of the DLLs in the troublesome installation (possibly renamed?), or the FSUIPC.KEY file isn't correct in that particular Modules folder. The FSUIPC.LOG file would tell me about the latter, but try copying your FS2004 KEY file over (again?). All the stuff both FSUIPC and WideFS deals with is in the Modules folder, so I suggest a good first step is to compare the "clean" modules folder with the suspect one. There must be some difference there causing the problem. When you find the differences, try eliminating them one by one till you've found the culprit, then get back to me. Don't delete anything, just move it into a temporary folder (I use a sub-folder in the Modules folder called "Saved" or "Others"). And don't rename anything, that makes it more confusing and it may still load if it looks like a DLL. Regards, Pete

There's some other threads here with the same question, and I think one of them even has a link to a website with a kit or example. Try scanning through the subject headings, maybe search on "module" in the title. My advice has always been: learn to write a proper C-language Gauge as per the older MS Panels SDKs, and you are over half way already. GAUs are just Modules loaded by Panels. Regards, Pete

TrafficLook makes assumptions to keep things easier. it assumes the Earth is flat as far as the TCAS data range is concerned, for instance. The formula I use is: =========================== //dHdg = result in degrees //dDst = computed distance "in radians (i.e. nms * PI / (180 * 60))" //dMyLat = User Latitude, degrees //dMyLon = User Longitude, degrees //pt = pointer to current AI TCAS_DATA struct //MagVar = mag variation at user aircraft as WORD from FSUIPC dHdg = (dMyLat == pt->lat) ? 90.0 : (180.0 * atan(fabs(dDst/(pt->lat-dMyLat))) / PI); if (dMyLat >= pt->lat) { if (dMyLon >= pt->lon) dHdg += 180.0; else dHdg = 180.0 - dHdg; } else if (dMyLon > pt->lon) dHdg = 360.0 - dHdg; // correct for magvar dHdg -= (MagVar * 360.0 / 65536.0); if (dHdg < 0.0) dHdg += 360.0; if (dHdg > 360.0) dHdg -= 360.0; ========================== I don't think this is very accurate, it only uses elementary trigonometry, but it seems good enough for my purposes. If you are using it for missile launching you'll need to be more accurate I expect! :D :D :D Regards, Pete

Ah, wellI did say I was prejudiced, didn't I? :) I take all your points on board, and will probably henceforth recommend all VB programmer's who ask me questions to upgrade to VB.NETbut tell me this, does it still change &H00008000 into &HFFFF8000 i.e. sign extend even though the zeroes are explicit? That alone makes me shiver! :? Regards, Pete

Latest Zip file for what? Sorry. I've also had some problems in the past with Logitech mouse drivers. I always use the default Windows ones these days. I don't know what they are doing. The problems I remember weren't in AdvDisplay though, they affected quite a few things when FS was running. Thanks! Regards, Pete

Mixture is not at all like an alternator switch or a light switch. It has a full range of values. If you mean a fuel switch for Jets, then a toggle switch will do the trick. Just program it to send "Full Lean" when turned off, and "Full Rich" when turned on. You can do that with one toggle switch in FSUIPC's buttons page. If you only have a momentary push button, then you can still do it but it means editing FSUIPC.INI. You can toggle a button flag (Button Flag Toggle) when it is pressed, and make the "Full Lean" or "Full Rich" action depend on the Flag state, so it does the two things alternately. Check the FSUIPC Advanced User's documentation. Regards, Pete

Yes, you can do that. But FSUIPC offers as an alternative a separate reverser axis facility. Just a single one (at present) which reverses all throttles. See the FSUIPC User Guide, Joystick section. Regards, Pete

Sorry, I don't understand. What's a "toggle mixture parameter?". There are 4 standard mixture controls in FS, other than the analogue axis ones. These are Mixture idle cut off (Ctrl+Shift+F1), Mixture Full Rich (Ctrl+Shift+F4), and the INC and DEC ones (Ctrl+Shift+F3 and F2, respectively). I've no idea what a "toggle" action would do, nor really why you'd want one. Please explain a bit more so I can understand. Regards, Pete

My GPSout module sends positional data out on a serial (COM) port. AutoRoute can be set to receive it on a serial (COM) port. If you have two such ports, or a USB-Serial port adapter or two, you can connect the null modem cable from one to the other port. This will certainly work if you get all the COM port identities sorted out correctly. I wouldn't guarantee very good performance on the part of either FS or Autoroute, though, unless you have a good fast PC! :) Regards, Pete

Since all axes are treated identically by the software, it just has to be a hardware issue. Probably a dry joint or a loose connector, something similar. You need to contact PFC for advice. They will probably give you instructions for dismantling and checking certain things inside. Otherwise, if it is a recent purchase, shipping it back for repair may be advisable. Regards, Pete

FS does not provide a reverser axis as such. There is a facility for this in FSUIPC, available to registered users. The FSUIPC facility, by default, uses the Mixture axis, not the Prop Pitch axis, but you can assign that if you like. it means editing the FSUIPC.INI file, as described in the FSUIPC Advanced User's Guide. Regards, Pete

Well I should probably just remove its connection with the FS prop sync. The facility itself shouldn't do any harm if folks don't use it, and I will tidy up the way it syncs things to use existing values rather than previous input values. I just think I shouldn't do anything with the FS prop sync at all for now. However, saying that, I have just received the first complaint (by private email for some reason) that what you experienced also occurred after upgrading to 1.72, without even using the Sync facility at allso I really don't understand how that happened. Maybe it's the power of suggestion, from this thread! :lol: Don't worry, you didn't. I've just got such a long list of things to do, some large, some not, that going backwards is rather frustrating. It was an easy facility to put in, which was why it ws done so quickly, but the aftermath has made it a big thing. Never mind. I'll sort it out. Regards, Pete

The calibration screen shows the same values as input to FS, so are you saying your aileron control doesn't work? There's no difference in treatment of any one axis over another in the PFC driver, with the exception of the Flaps axis with detentes. If you are getting problems on one axis only I think you should contact PFC as it sounds like the hardware may be playing up. I saw that announcement. I have no idea what they are on about. Trying to scare folks for some reason. The older (pre Version 3.xx) versions of FSUIPC do not run in FS2004 in any case. FS will say it cannot run that DLL , and give you the option to try in any case, and then you say no. Regards, Pete

Ideally, through the HID and normal assignments, as then you have Windows calibration, FS sensitivity settings and FSUIPC Joystick facilities at your disposal. If, for some odd reason, you cannot use the normal joystick interface then you can still send the values as the appropriate Axis controls, via FSUIPCs offset 3110. This bypasses Windows calibration and FS assignment and sensitivity, but will retain the FSUIPC options. The facility to write directy to the control values themselves affords no reassignment, no calibration, nothing. You have to do all that yourself. This is the way external and some sophisticated panels control those things for either Autopilot use of "fly-by-Wire". If you don't want to use any such sophisticated panel or external system (like Project Magenta) for example, then by all means write to the FSUIPC control locations (0BB2 etc). You bypass everything then. I don't know why, as they are all surely described in entirely different words? For even more different words: 0BB2 is the elevator control value, the final control sent to the actuator. 3110 is a facility for sending any of the Controls listed in my Controls List, and otherwise identical to assigning these in FS Assignments or FS CFG file. 3328 Is a READ-ONLY area showing the axis input value which would have gone to the control value if not disconnected by 310A. As described, it is this which allows Fly-by-Wire implementations -- the FBW module can diconnect the input value from the control value, read the former, manipulate is as it likes, and then forward it. Regards, Pete

But what does it do then? If I leave it in will I get complaints from others who say I've mucked up their cockpit now and stopped Prop Sync doing what it is really supposed to do? This is happening al the time now -- almost everything I put in is not liked by someone or other. Pete

The interface is a combination of EPICINFO (for displays) and normal FS assignments (for inputs), using POVs for radio frequencies and so forth. I only added the POV stuff to EPICINFO for FS2002 and later because when FS changed to DirectInput is messed the normal assignment of POVs up completely. In FS95, FS98 and FS2000 (yes, EPICINFO has been around for all of those), every single input to FS was by assignments in the FS CFG file, and EPICINFO was exactly as it's name ssuggests -- info to EPIC. Most of the specific stuff for the KR-1 was EPL derived from the EPL for the TR-1, and pretty much none of what I wrote originally is compatible with today's USB EPICs and new EPL syntax and facilities. It was all re-written for the new stuff by Ralph of R&R. I don't do any EPL programming now and would probably be quite bemused by what my own code has become! Regards, Pete