Pete Dowson

No sorry. Best to ask others their opinion. Regards, Pete

I gave up trying to figure out FS's time shenanigans. Try the freeware "FSRealTime". I use that. Make sure you get the FS2004 version though. Regards, Pete

It will be faster by by-passing PANELS.DLL and the sending of the control via Windows message queue (that's all PANELS.DLL does with the key events). FSUIPC writes directly to the switch location in the simulation engine. Of course, you have to offset that against the call, via a SendMessage, you need to make to FSUIPC. I doubt you'd be able to measure the difference really, and it won't matter in any case unless it's a frequent event. Not really. You could try intercepting the control -- you'd need to subclass FS's FS98MAIN window and trap the WM_COMMAND with that control number. Not sure what you'd do with it though. Regards, Pete

Please try again, then close down FS. Get the FSUIPC.LOG and FSUIPC.KEY files from the Modules folder, ZIP them up and send them to me at petedowson@btconnect.com. Regards, Pete

What product? FS2004 I presume you mean? Well, on the contrary, I do think it is their fault. When the wind changes direction the ATC should reassign aircraft not actually on finals to the new runway. It doesn't matter where the weather comes from -- the same applies to FS's own weather settings or downloads! Someone has mentioned that since the FS9.1 update this does happen, but I've not noticed it. Mind you, I don't get time to fly that often. Sorry, you've lost me. I just meant, instead of toggling it twice when the weather is set, do the first toggle earlier, so that FS doesn't waste time driving AI aircraft around when you are going to remove them later in any case. Remember, the process to get them restarted is to toggle them off, then on again. There's no reason those two actions need to be together. The first one (switching off) seems to be almost instantaneous in effect, so I guess you don't need to count to five or anything in between. Sorry, this is not an area I've researched. Well, I'm an Ultimate Traffic fan, with a lot more than the default, so it affects me a lot more. I've always used 100% It needs to be in the program. I don't know how to enforce that. I have similar issues with the only program I run in addition to FS on my FS PC -- Project Magenta's MCP program. It runs okay in the background, but during loading it displays a PM identity graphic which forces Windows from FS full screen mode (on 3 Parhelia monitors) into windows just to show me, minimising FS as a result. I always have to click the FS icon in the task bar afterwards. I keep meaning to have words with Enrico about that. Regards Pete

Ah, right. Strange. Anyway, glad you are all sorted. No need, it can stand in case others are interested. I only delete topics containing profanities or generally consisting of upsetting stuff. Luckily I've not needed to do more than twice since establishing the forum. We have a nice crowd here. Regards, Pete

I know next to nothing about Airbus's I'm afraid, and certainly nothing much about the PSS cockpits. Maybe someone here can help, but I think you'll be better off asking in the PSS forum, if they have one, or at least in the FS2004 forum near here. I don't think there's anything in FSUIPC which will have any such influence on the PSS code one way or the other. Regards, Pete

It isn't really a lot to do with any version of FSUIPC, other than using a version 3.12 or later, when the Traffic Density Toggle control was added to the Buttons and Keys lists of controls. I don't know about 'best' method. Before I added that control the method some folks used was to wait until the weather was set for the departure airport, then change airports -- go somewhere a good 50-100 miles away at least. Then return. FS will restart its traffic. With the FSUIPC control, I just run FSMeteo (or ActiveSky), let it set the weather up whilst I'm busy pre-flighting, generating my plan and setting up Radar Contact and the FMS, then, when the weather is clearly set, press my key combination which is programmed to "Traffic Density toggle" -- twice (first time zeroes the traffic, second restores the previous percentage). That's it. Actually, thinking about it, it would probably be a bit better to toggle it "off" to start with, so FS doesn't both with AI traffic for a while, then just toggle it back "on" when ready. Someone did ask if the weather program could do this automatically, and I did say, yes, it could -- since version 3.40 of FSUIPC -- as the added FSUIPC controls can be instigated through the FSUIPC interface just like the FS controls. Maybe this is where the confusion arises? I think the person who asked was going to go off and suggest it to whoever writes his favoured weather program. For myself, I am not really in favour of it being done automatically because, whilst zeroing traffic is almost instantaneous, toggling it back to, say, 100%, can take a noticeable time during which you get a progress bar on screen. How long it takes depends on how much traffic you've added. Personally, I'd rather this was under my control. Regards, Pete

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