Pete Dowson

What version of FSUIPC are you using? Is it user-registered? What version of FS? It certainly isn't an error report by FSUIPC, so it must be from a gauge in your aircraft. I'm guessing, but possibly it is simply reporting an error return number from the FSUIPC access library code they are using, rather than translate it into a message. Here's a list of such numbers: 1 Attempt to Open when already Open 2 Cannot link to FSUIPC or WideClient 3 Failed to Register common message with Windows 4 Failed to create Atom for mapping filename 5 Failed to create a file mapping object 6 Failed to open a view to the file map 7 Incorrect version of FSUIPC, or not FSUIPC 8 Sim is not version requested 9 Call cannot execute, link not Open 10 Call cannot execute: no requests accumulated 11 IPC timed out all retries 12 IPC sendmessage failed all retries 13 IPC request contains bad data 14 Maybe running on WideClient, but FS not running on Server, or wrong FSUIPC 15 Read or Write request cannot be added, memory for Process is full If this guess is correct, then they don't seem to like the FSUIPC version number or their code doesn't recognise it. The answer may be in the FSUIPC Log file. Do a short run, and close FS, then ZIP up the FSUIPC LOG file (from the Modules folder) and send it to me at petedowson@btconnect.com. Please include your FSUIPC.KEY file too in case it is related to the registration. Regards, Pete

No, it is not. I've just downloaded it to check and it is fine. Please read the notes at the top of that web page, especially the bit in red saying: If you download a version which is not the same as displayed on this page, *please* empty your browser's cache or make sure you have specified the right download folder, thank you. Also try pressing Ctrl-F5 which should force a direct reload of the page in case your ISP is caching any links on this page This happens to a few folks every single time a new version of anything is uploaded, and may simply indicate that your ISP is configured incorrectly and doesn't update its cache when file dates change. If so, then apart from complaining to your IPS and/or waiting a few more days the only other thing I know is to change ISPs. Regards, Pete

I understand that, but what did CH supply to enable you to make use of this directly in FS, without FSUIPC? Surely they don't actually say "to use this you need to buy FSUIPC as well"? The values you are telling me which are coming through, before FSUIPC manipulates them for you, just won't give you idle at the detente, but a long way above it. Furthermore, the maximum reverse on most aircraft is only a quarter of the full thrust (though it varies somewhat), so the full reverse value would be -4096 or thereabouts. All the negative range below that is wasted lever movement. FSUIPC can help you sort this out, as it will massage whatever input figures it gets to fit what is needed. I just find it puzzling as to what CH's intent was, here. How do they expect it to work? Really, for best results, you should first see if you can get it working more or less correctly without using FSUIPC, then just refine the figures and give yourself good reliable full thrust and idle zones via FSUIPC. Regards, Pete

What do the values shown look like? What's in the IN and OUT and in each of the other boxes? I need to understand what you are seeing. Pete

What values are those? The input (IN) values from the device? Is the "idle" value the reading when at the detente on the lever, is it? Ernot direct to FS they wouldn't be, no. Forgetting FSUIPC for the moment, is this new CH device supposed to support reverse thrust on their levers out-of-the-box? Do they say that? If so, and these values are the input values you are seeing in FSUIPC, then they are way out, and you need to sort out the CH drivers and/or their proper calibration in windows, and ensure the FS sensitivity slider is at max and null zone low or zero. As far as FSUIPC is concerned, however, the IN values don't matter much. Providing they are enough of a range to give you reliable operation then they don't matter. Be sure to calibrate, on the 4-throttles page, a reasonable range for the idle ("centre") both slightly above and slightly below the detente so that any jitter or slight variation (and there's always a little variation -- temperature, humidity, etc) is ignored and you can get a good stable idle. No. You have to use the individual throttles though, not the single throttle on FSUIPC's page 1 of 8. If you are only using a single throttle lever you need to map it to 4 throttles on page 1 then calibrate on the 4 throttles page. All that is explained in the FSUIPC User Guide. If you are using separate throttles for each engine (check the FS Assignments) then you don't use the Page 1 throttle at all. They are meaningless to me as they go through a heap of processing in Windows and in FS itself before FSUIPC sees them. All FSUIPC is doing is manipulating the results. If those values were to work correctly in FS without FSUIPC, the reverse should arrive as -4096 or so, the idle as 0, and the max as 16384. This is what FSUIPC will calibrate them to. If the quadrant is supposed to work without FSUIPC there's something wrong somewhere between the CH driver/manager and what comes through FS. Regards, Pete

Aha! So, no AIBridge is needed. Ah, yes. Thanks for the clarification. My database doesn't record so much detail for Modules and Gauges I'm afraid. Regards, Pete

ZIP up your FSUIPC Log (with 3.41 or 3.411 of course), plus your original FSUIPC.KEY file, and send to me at petedowson@btconnect.com and I'll check it out. Better also include your original key notification (from SimMarket progably?) is case I need to sort it out here. Regards, Pete

If there's no serial (COM) port on the laptop then the only thing I can think of is getting a USB serial port -- and adapter which plugs into a USB socket and comes with a driver which makes it look to Windows like a COM port. I use several -- there never seem to be enough COM ports! If you've neither a COM port nor USB then, I'm sorry, but I don't know of any solution. Maybe there's a serial port adapter for a printer port, but I've not heard of one. BTW, a "null modem cable" is actualy more complex than that needed by GPSout. Since it only outputs data, it doesn't need the input connection, so basically it comes down to two wires -- a common return link, and the TX-out on the FS PC connected to the RX-in on the receiving PC. The term "null modem" comes about because if you want to buy rather than make a cable, that's the name the correct cross-over cables usually go by. A cross-over is needed between two PC COM ports because an ordinary straight connection cable ("RS232 extension cable", probably) would link RX to RX and TX to TX -- no good at all. Regards, Pete

Well, I really do have enough on my plate, thanks anyway. Not being an EPIC user and having almost zero experience of the EPICUSB incarnation of EPL would put me at a severe disadvantage in any case. No, not at all. MOST of the work in in sorting your EPIC programing out. Once you've mastered that I don't think you'll find any of the ways of interfacing to FS, be it EPICINFO or the other (is it FSCommunicator? Sorry I can't remember off-hand) any problem. All my EPIC experience dates back at least six years (more) and is documented in the EPIC95 and EPICINFO packages. There are old EPL examples in the EPIC95 package -- the name shows its age, Windows 95 -- but they are not so good for EPICUSB. They may be partly instructive but best after you've learned the new EPL. Yes, of course. That's part of the whole point of having something as sophisticated as EPIC. You can program whole aircraft subsystems with it and only deal with FS where needed. I started off like that, but this was years and years ago, and none of what I know is applicable any more. Yes, I'm always complaining about that. This is why I don't use any FS panel at all, and moved over completely to Project Magenta instrumentation. Take a look some time at the Beta Demo of pmSystems -- that certainly looks like it can be used, eventually, to program any subsystem very well, and all through easy text files. The examples at present have 737 and Airbus overheads. That's a problem, really. I don't think I could recommend EPIC to anyone who wasn't going to learn how to program it. It is a very powerful idea and well executed, but you certainly have to work hard at it. You not only have to learn your aircraft systems inside-out, but also hardware, electrical wiring, assembly, AND programming. Regards, Pete

Yes, I will. I was very surprised too, not so much with it's performance compared with TCP/IP (here it is slightly better, nothing to write home about). What amazed me was that I had none of the difficulties I had originally when I first tried it with WinXP. The only difference here, really, is XP's SP1 (I've not dared install SP2 yet). So I can only put the original troubles down to possible bugs in the first XP release. Regards, Pete

Yes, indeed it is. Please download the FSUIPC SDK from http://www.schiratti.com/dowson, and check the Programmers' Guide. In particular, you will find not only Pitch, Bank and Heading (PBH -- FS terminology), but also the current velocities in each of the 6 axes of freedom, and the accelerations as well. I think, for motion platforms, you will be better using accelerations than actual current values, as you need to derive differences anyway. Regards, Pete

Your first step is to download the FSUIPC SDK from http://www.schiratti.com/dowson Regards, Pete

It's fixed. Version 2.13 is being released later today. Regards, Pete

If your EPIC produces button presses which are recognised in FSUIPC, then you can program them in the Buttons page. FSUIPC does include code for reading EPIC buttons, whether EPICISA or EPICUSB. The main interface to FSUIPC from EPIC that I produced is in my EPICINFO module, which started off only as a way of getting data out to the EPIC but now also has ways of directly writing to FSUIPC offsets. However, I do not use EPIC any more and I'm afraid I would find it very hard to support EPICINFO. It is still "current", in that it works, and I may be able to answer specific questions, but really most of the knowledge you need is in programming the EPIC itself. The parameters for EPICINFO etc are relatively trivial in comparison. These days I think more and more EPIC users have turned to using other software to interface EPIC to FS -- it works through FSUIPC also, as the interface, and is probably easier to use than EPICINFO. I noticed this on the EPIC Users mail list today, also from an Arthur (coincidence?). It may help: Regards, Pete

You need to make the idle zone (centre "Set" button) wider, to encompass the detente completely. It sounds like the values you've calibrated for centre are not very good. When calibrating put the lever forward slightly of the detente and press the centre Set, then back of the detente a little and press it again. Which numbers? IN or OUT? The "OUT" values are results of how you calibrate in FSUIPC. The "IN" numbers are what FS is deriving from your axes. If the IN values do not appear to have much range, there are two possible reasons. First is that the Windows calibration is bad (Game Controllers, or whatever drivers they come with). Second is that the FS Sensitivity is wrong. For full range you need maximum sensitivity. Well even a small difference would be scaled by FS to meet the complete range. You'd just get less actual positions giving different results. However, if this shows in Windows calibrations then either the pot in the device is very off-centred or something else is wrong with the device. Regards, Pete

Okay. Nevertheless, there appears to be something wrong with your user Key. Please send your FSUIPC.KEY file to me at petedowson@btconnect.com, and also, if possible, the original notification details (from SimMarket? Or wherever). I'll see if I can sort out what has happened. Regards, Pete

Ugh! Not a good idea. You should never have to do that, not unless you haven't updated FSUIPC for a year or more! Even then you still lose all your settings for nothing! Erregistration?! You deleted your FSUIPC.KEY file as well? Good grief! Never do that unless you really want to re-register. And then be VERY VERY careful that you enter everything exactly right! The difference between versions does not normally affect anything in the INI files, and most certainly nothing in the registration. As documented, updating FSUIPC is simply a matter of copying in the FSUIPC.DLL file. There's most certainly nothing changed in FSUIPC that would affect any of that. Even entering your registration incorrectly wouldn't do that, as the PMDG aircraft have their own accredited access key. The first place to look is the FSUIPC.LOG file. What does that show? Please just start up FS with FSUIPC 3.411 installed, then close FS, and show me the entire FSUIPC Log file (from the modules folder). Regards, Pete Regards, Pete

What "TQ" is that? If it's the Goflight, doesn't it have a little separate reverse lever which operates a button to put it into reverse? If not the GF TQ, then what instructions are you following to calibrate your throttle, and what is this "detente"? FSUIPC's main single thorttle calibration, on Page 1 of 8, doesn't provide for a reverse range. No idea, I'm afraid. I am having trouble picturing what you are doing. First, though, have you calibrated the levers properly in Windows (Game Controllers, or whatever drivers they came with)? The other thing to check is that you have full sensitivity and no null zones set at all in FS's Sensitivities menu. Remember, FS processes all this before FSUIPC sees it -- FSUIPC is merely manipulating things at the final moment before FS's sim engine gets hold of the values. Regards, Pete

Not read only (well, the GPS area may be), it is just that writing a value has n effect because it will immediately be overwritten again by the simulation engine. Is this Reality software the gauge or DLL I'm vaguely aware of? If so it doesn't use FSUIPC. I expect it reads this stuff like any gauge would -- through the panels interface to obtain values direct from FS. There's really no way I can influence that. Virtualy all "Offsets" these days are only available to FSUIPC clients Regards, Pete

On further testing, I don't think it is a change in 9.1. As far as I can see, AdvDisplay has NEVER been able to detect a reload of the same panel -- it works perfectly well if you change to another aircraft then back again! Checking the code, I think it has always been like this, for years! Strange that no one has reported it before! Anyway, I think I should be able to fix it fairly quickly. If not soon it will be Monday. Either way, I am sure it isn't anything to do with flashing panel parts. That may be what brought your attention to the disappearing AdvDisplay window, but I'm sure it isn't related. Basically, what is happening in my DLL after the panel is reloaded is that all of the Window handles that AdvDisplay knows are different and it then simple isn't aware of anything it needs to do. So it does nothing! I need to find a way to detect a panel reload and treat it like a new panel. Regards, Pete

Okay, I was wrong. I don't get flashing panels, but I am losing the docked AdvDisplay window when reloading the aircraft. That's very strange. I don't understand what has changed there. It isn't anything to do with having RC running or "hide when empty", and the FSUIPC Hotkey doesn't bring it back either. Evidently something HAS changed in FS9.1 which affects AdvDisplay. Terribly sorry. I'll get onto this right away. But it may be next week some time before I have a solution. We have guests over the weekend. Regards, Pete

What panel part is it docked to? Is the name for it correct in the [AdvDisplay] section of the PANEL.CFG file? There are some advanced panels which AdvDisplay has difficulty docking to automatically -- with those you can either try doing it manually (by editing the CFG file), or just use "Lock" instead of "Dock" and the FSUIPC hot key to hide and re-display is when you want to. You main panel flashes on and off??? Phew. That's a serious problem!! Do you have "render to texture" set in the Options-Settings-Hardware-Display options? If so turn it off. That's the only "feature" I know of that can cause panel flashing. No, it sounds rather like you have a problem which also affects AdvDisplay. There's been no change to anything in AdvDisplay in well over a year and it seems to work perfectly here [bUT! Now see next message!]. I know of no change in FS9.1 which would upset it, and least not program-wise. Try windowed mode instead of full screen. Does that make a difference? Have you changed any of your video settings? Maybe the FS9.1 update, which included a revised "Display.cfg" file I think, upset some of the settings FS is using for your particular display -- during testing one such problem was discovered in its Matrox Parhelia settings, fixed before release. If you tell me exactly what your video card is I should be able to compare the Display.cfg entries before and after FS9.1 -- I have a "virgin" FS9.0 installation still, for base testing. Regards, Pete

That's okay. Version 3.411 is there now, I just checked. Regards, Pete

Many USB connections emulate ordinary serial ports (COMn) at the PC end. See if yours is listed in the Settings-Control Panel-System-Hardware-Device manager list under "Ports COM and LPT" or similar. I know my iPaq isn't, nor my Garmin iQue 3600. :cry: Things aren't that easy. If the socket on the PDA is true USB the electrical and protocol characteristics are entirely different. Regards, Pete

Have you asked him why they don't work? Maybe he's using something particular to FS9.0 and they won't work with the 9.1 update? Regards, Pete