Pete Dowson

I assume you mean the visual switches on the cockpit overhead, not the controls and indications themselves? Both 2D and VC? I'll have a look here. Regards Pete

What in the PFD is there from your waypoint to be updated? Surely both the PFD display and the ND are in one window, from one program (PFD.EXE) on your client? That sounds absolutely awful. What does PM support say? Have you checked the performance of the PFD display on that client? If you press 'F' (I think) it will display the assorted frame rates - graphic, data and FS. A process of elimination would be useful too. Try just the PFD client without the CDU.MCP -- fly with the FS autopilot if necessary. See if the gagues perform responsively. Then try the MCP only, using FS defauult instruments to see what you are doing. and so on. You really do need to narrow it down. Please, it isn't any good sending me PM logs -- they are for PM support. I assume you are talking to them? What is your average frame rate in FSX by the way. It looks too good to be true for a mere 3GHz PC from the Logs -- averaging 16 frames per second update rates on both clients. Are you only flying in country areas with no autogen? I can't get such good frame rates with the release version of FSX on a Pentium Core2 Extreme 6800! Have you tried limiting the frame rate in FSX? If you are really achieving 16 average, try limiting it to 15 or 16. Is FSX your first FS with WideFS and PM? If not, can you make sure it all runs well on FS2004 or FS2002 first? Now this WideServer log is nothing like the previous one you posted, which showed no errors at all for 2659 seconds (44 minutes) when you closed down. Now you show disconnections and reconnections several times over the course of 3335 seconds (56 minutes), starting after only 8 minutes! Why is this one different to the last? What was different in what you did? It LOOKS like you simply closed and restarted the Clients several times, hence the disconnections. I say this because the two error-free Client logs you supply start at 17:05, a full 41 minutes after WideServer started, so only relate to the last 15 minutes of the session during which there were no errors logged. There are no problems shown in the logs, though of course you aren't showing me the whole story by supplying a WideServer log for 56 minutes with Clients relating only to the last 15. I can only think of three possibilities: 1) Data is getting queued in the TCP/IP link from FSX to SimConnect, and that queue is building up. I don't think this is that likely, but there have been one or two cases reported, early on, with such symptoms -- even on a single machine, not PM. I think these were fixed by uninstalling firewall and security programs and moving to ones known to work okay with FSX -- Windows XP's firewall is okay, and I think AVG and Norton Antivirus are okay. Note that merely disabling them doesn't fix anything, they have to be completely uninstalled in order to remove the hooks that are getting in the way. 2) Data is, for some reason, piling up in the memory buffers of the Fs Pc (the Server) because it isn't being swallowed fast enough across the Network. This could, I suppose, be a wiring or hub problem, or maybe even a Network Card or Network driver problem. Check all of these -- reinstall the Network cards and their drivers (literally if necessary). Try alternative network cards if available. Don't use Wireless. 3) Data is piling up in the Client TCP/IP queues because WideClient isn't getting enough time to process it. Since the PM programs aren't that heavy on processor usage, this is more likely to apply to the PFD PC and be down to graphics drivers taking the processor for large chunks of the time. This has been quite a common cause in the past -- you need video cards and drivers properly supporting OpenGL hardware acceleration and working well. The CDU and MCP don't use OpenGL (well, it is an option on the CDU but I've never used it). If the problem really is on the PFD PC, and the CDU/MCP work okay without it, then this really is the most likely. You should discuss these sorts of problems on the PM forums, because there will be folks who had this and dealt with it before. PM used to have their own Newgroups/Forums, but sadly they don't now. Try the group at MyCockpit. http://www.mycockpit.org/forums/forumdi27981&f=99 Regards Pete

One other observation: Have you perhaps got Client1 and 2 named the other way around from your description? I would expect next to zero data reception at the server from the PFD program, which is a display only, but qute a bit from the CDU and, especially, the MCP which is controlling the plane during autopilot modes. Regards Pete

Are you sure these are Network problems and not problems with the graphics drivers for the PFDs? "Abends" meaning what, precisely? Is there an error report, a hang, or what? No problems according to the WideServer Log, but the other logs you provide are for PM, not I. I'm afraid you need PM support for those. Are there any errors listed in the Wideclient logs on the clients? And please also check the FSUIPC4.LOG, as any problems with SimConnect may cause stuttering -- not crashes nor hangs however. If your PFDs are crashing the most likely suspect is video drivers on the clients. PM support may be able to help. BTW, it probably isn't terribly important, but I think it best if you run the latest versions of WideClient on the two client PCs -- 6.72. Regards Pete

Really? How did it do that? Sorry, that is something I don't recall at all. Can you provide a reference? The only thing to do with default flights was this, in FSUIPC3, corrected in January 2006 after being that way for five years: This cannot apply to FSX because there's no interception of any routines in FSX. The information and facilities relating to Flights is provided nicely by the SimConnect interface. Regards Pete

http://kennethhunt.com/archives/000933.html Thanks! Useful! ;-) Pete

I don't know, I've never tried. It just passes the whole string onto a Windows API to create the process, so if that API procedure accepts these codes then it would work, otherwise it wouldn't. The facilities for %...% are new to me -- I've seen them in other places, but I know nothing about them anyway. What does %homepath% do, exactly? And where did you get it from? Is there a list of these someplace? I suspect that they are macros only recognised by the Windows Shell. Possibly if I executed the programs via Shell calls it would work -- but I cannot do that and also automatically get the process handle, which I need for the other options I support. Also I cannot assume the facilities will be available on all systems supporting FS98 to FS2004. Have you looked at FSAutoStart or other similar programs? I think they can load stuff as well as closing processes you don't need. Whether they use Shell calls or not I don't know. Regards Pete

Good. I'd be grateful if you would confirm this to Simkits / TRC support. Thanks, Pete

No, it can't be okay, because FSUIPC4 is not FSUIPC3. They are different products. An FSUIPC3 keywon't work with FSUIPC4. Please check the documentation, and the sales booths at SimMarket. Regards Pete

Not off-topic. I'n here to answer questions on all my FS-related programs. The main functions of that program were not for FS at all, but more for Radar Contact, Squawkbox, and Project Magenta (and, going a long way back, EFIS98). And of course quite a lot of other programs that can use SBP and FS PLN text formats. I understood that FSX could actually still read older FS PLN formats too, even though it doesn't output them. I've never tried (I use Project Magenta and Radar Contact with FS2004 and FSX). Have you tried? Have a go and let me know. Yes. Horrible, aren't they? Try with the older plans and let me know. If needed I can look at doing an update to produce XML plans but it'll have to fit in between more pressing things. Regards Pete

Ah. Thanks for pointing that out. That's a left-over from the original section there accompanying the previous interim update. That should now read "in a Boxed section in the User Guide", as, of course, as always, it was incorporated in updated User documentation for the main 3.74 release, thus: I would have thought that the subject of this note was obvious from the original text in the Announcement however. Why did you think it might apply to you? It was a new facility, but only available by INI editing, as it said. Hmm. Unless this is a signature or key problem that is indeed rather odd. Nothing is changed in the actual interface that should affect things so much. I always strive to maintain backward compatibility even when adding new features. The log file shows nothing out of the ordinary. Everything looks fine. I am afraid I am at a loss to know what differences your FSCargo program finds between 3.71 and 3.741. Possibly it is making some presumptions about previously unassigned areas of FSUIPC offsets which have now found some use. Either that or, indeed, somehow I have made a mess of somerthing it needs. But I am realy not in the correct position to determine what the problem might be. Sorry. Can you get the FSCargo folks to check, and get in touch with me if there is really a problem. If possible i will fix it as soon as i know. Regards Pete

Only the FSUIPC INI and KEY files, from the FS Modules folder. You'll still need to re-register afterwards, but you can cut and paste from the FSUIPC.KEY file, which is a text file. Regards Pete

I'm not sure what you are really saying, but it sounds like you mean that FSUIPC4 is giving you problems, and that, in fact, IVAP is completely irrelevant. Correct? If so, please tell me exactly what is going wrong, and show me the FSUIPC4.LOG file -- you can get it from the FSX\Modules folder. I cannot do anything at all without any information! I don't know how you expect me to! So you do not care if things are fixed or not? you do not care if other people have problems? Why did you bother to write to this Forum if you don't want any help? If you expect to get help you must surely realise that you must provide some information. How else can anyone help? You have sent many messages already, and none of them actually contain any description of your problems! Pete

I really do hope you do not mean the "first version" of FSUIPC -- you must always use the current, latest, version. 4.09 at present. And as I said, there are no apparent problems using ONE SimConnect client. SimConnect seems to have problems with MULTIPLE (i.e. more than one) clients when FSX gets busy. You say IVAP works without FSUIPC4. Try FSUIPC4 without IVAP. That works too, right? Together: 1 + 1 = 2, that is MULTIPLE clients for SimConnect, and that's where, when FSX gets busy, it falls down. There is NO INTERACTION between FSUIPC4 and IVAP, it is NOT FSUIP4 causing problems for IVAP, just as it isn't IVAP causing problems for FSUIPC4. I know you don't understand English, but please get this translated properly so I don't have to keep repeating myself. I might be able to help a bit if only you'd provide some information, but you do not! Regards Pete

I'm sorry, I don't know. They won't be specifically problems between IVAP and FSUIPC, but instead both with SimConnect (part of FSX) -- it is known that SimConnect can have problems with multiple clients, especially when it gets heavily loaded. There are two ways to find out more -- look at the FSUIPC4.LOG, in the FSX Modules folder, and check SimConnect. Ways of getting SimConnect Logs and of re-installing SimConnect are provided in the FSX Help Announcement above. We are hoping that the forthcoming SP1 update for FSX will fix a lot of the SimConnect problems people are facing, but whether it does or not is unknown at this time. Regards Pete

I've no idea what you are asking I'm afraid. If you want some help please try to describe the problem, not simply say "it has never worked" which doesn't really help at all. Also please state the versions of everything involved, -- if not the latest supported releases, try those first, and show the FSUIPC4.Log file so I can see if it is one of the known SimConnect problems. And have you asked IVAP support? Regards Pete

FSUIPC doesn't get involved in any of that stuff. It sounds like some add-on program is doing things. Can you please detail all the add-on programs you are using? No, you never have to make changes in the INI -- where did you read that? Start FS with FSUIPC 3.741 installed, get the problems, close FS down, show me the ocmplete FSUIPC.LOG file please. Regards Pete

USB ports are simply the "new" serial ports. The name isn't "COMn" that's all, but something more complicated and longer. There's an example someone provided me in the GPSout docs. I think the main problem with GPS's is that the USB connection connects to some sort of Active Sync driver which you will have already installed. It is not easy to disable that to free the connection for other programs. On top of that, whilst the 396 may be okay (I don't know), very few GPSs actually provide any way to feed in positional values to override their in-built GPS system -- and many of those that do do so for external antennae systems which have a totally different type of output. The few GPSs which do allow NMEA positional or Aviation input are specialist aviation GPSs. There seems to be a general misunderstanding that my GPSout system is designed to drive GPS's. It isn't. The very opposite is true. It is designed to make the whole of the PC running FS look like a GPS for those programs, moving maps and the like, which are designed to take their input from the OUTPUT of a GPS -- hence the name "GPS OUT". Ah, well, in that case it will be a matter of uninstalling or otherwise disabling the Active Sync program which insists on grabbing it as soon as you plug it in, and finding the correct port name for the USB connection. It'll be something like "\\.\WCEUSBSH001", as far as I know. Good luck! Regards Pete

Er .. only if you are assigning the axes themselves in FSUIPC. That is clearly documented. The joystick calibrations section can deal with FS or FSUIPC assignments -- the mapping of 2 to 4 throttles is on the 4 throttles calibration page. I'm sorry, but your replies are leading to more and more confusion. What are you using and where? Have you calibrated at all in FSUIPC? In that case it won't be anything to do with the joystick at all, as that will be ignored -- unless of course that PMDG option only ignores the normal "one for all" throttle assignment, and not the individual ones. Also, there are two sets of individual assignments -- the "THROTTLEn SET" ones, which include a reverse zone, and the newer "AXIS_THROTTLEn_SET" ones, which don't. There's an option on the FSUIPC 4 throttles calibration page to avoid interfering with one set -- did you try it? If the IN value carries on rising whilst the OUT value stops at 16383 or 16384, then there is a max dead zone, yes. But surely you'd know this because you yourself would have set it during calibration? Ignore the VC, look only at the main quadrant graphic in the 2D panel. I don't believe half of the VC graphics. And for more accuracy, seeing exactly what is going on, compare the changes in IN values in relation to the OUT values, in FSUIPC, as you move the lever. Regards Pete

But, I ask again, HOW are you mapping them so? not by FSUIPC at all I think. FSUIPC provides options for 1+2 and 3+4 from 2 throttles. Ah, but have you got a calibrated "dead" zone there at all? Sorry, but I'm really not in the picture here -- what are you using FSUIPC for in this, and if not in FSUIPC where are you doing these assignments and mapping? Are you trying to use the CH manager program -- if so I think there is a better place for you to go to get help: http://www.ch-hangar.com Regards Pete

Well, I can't see why. Such behaviour is normally down to jitter in the actual throttle axes. Provided there are no changes seen on the joystick axes, nothing from them is ever sent to FS. (This applies always, no matter whether you use FSUIPC or not). Normally, for all aircraft and all versions of FS, whether FSUIPC is used or not, when in auto-throttle modes you need to ensure that the actual throttle axis values aren't interfering. Unless you have absolutely clean non-jittery axes (very rare) this is normally achieved by parking the levers at idle or max settings, where you will, of course, have calibrated a reliable dead zone which therefore will not jitter. One procedure that works well is to move the levers to max when engaging the A/T on climb, and remember to pull them back to idle some time during cruise, when or before you start descent. Well, if it is only related to the PMDG aircraft I really have no idea what could be causing it, as jitter should affect all. Of course, it depends how the auto-throttle is actually managed in the particular aircraft. What about the default 737, for instance? And did you try inducing some real "jitter" (move the throttle levers up and down in the Level D and PIC modela with A/T engaged. Don't see why. Sorry. How exactly have ot assigned them in any case? You said: but you don't say how. That is a rather unusual choice for 2 to 4 engine mappingyou get no asymmetric thrust facilities, for use when flying with an engine out or for steering assistance when taxiing. The normal mapping would be left (1+2) and right (3+4). Regards Pete

Ahyou are the "Geoff D" on the Beta group? Why aren't we discussing this there, then? Well, FSUIPC4 is of course always receiving changes in the Transponder code, so it can populate the Offsets and supply such values readily to its own clients. If you think that a simple TransmitClientEvent back to SimConnect, presumably of an XPNDR_SET control, might "fix" it, then I can add it in now for you to try (just in case, as it were). What would worry me, however, is the latency imposed by SimConnect's use of TCP/IP asynchronous stacks and the associated queues. Supposing someone is incrementing through valuesx, x+1, x+2etc. By the time FSUIPC received the x+1 value the actual transponder might be already on x+2, and if FSUIPC then transmits the x+1 back, by the time that arrives the correct value might be x+3. This would effectively end up in a never-ending loop with nothing actually getting done properly at all! The only possible way out of that I can think of is for FSUIPC not to send any changed value until it has remained unchanged for a period of time, perhaps as much as a second. There's still a possibility that this would conflict with another change though. I wouldn't agree to it unless the above worries are resolved. I may have to insert some test code, with an adjustable delay (milliseconds up to several seconds), and only set the code as permanent after thorough testing. Regards Pete

If there's nothing strange in the FSUIPC.LOG (did you look?) then it's a process of elimination, then. First remove FSUIPC to be sure it is related to an add-on. Then put it back and try without each one in turn. Of course, always make sure you are using the latest version of FSUIPC. ;-) Pete

I didn't even know the MP system was so pro-active. Do the MP packets contain everything about an aircraft? But if it changes on screen, and is recognised by everything else as being changed, and only the "MP system" is excepted, then surely it must be an MP issue? Well, I'm not sure what "events" these are. The Simconnect interface for this certainly works 100% -- including using the XPNDR_1_DEC/INC, 10, 100 and 1000 controls. They all change the actual transponder value and the changed Transponder code is sent to any Simconnect clients who've asked to receive such changes. .Well, yes, it is their code. And as it does only appear to affect the MP system it explains why I really have no idea. There's nothing in any of my explorations in this or previous versions of FS which overlaps with MP I'm afraid. Sorry. Only in areas I know, and I'm afraid MP is not one. There's nothing appearently wrong with the Transponder stuff in all the areas I deal with. What methods are you talking about for these "reads" and "writes"? SimConnect? You are talking a slightly different FS language to the one I know. Are you talking as a Gauge programmer? If you think there is a bug, have you sent it to FS? Try reporting it, in detail, via tell_fs@microsoft.com. Well, if this is simply a SimConnect "TransmitClientEvent", yes, it could be done. But I'd really very much prefer that it be fixed at source. After all, Microsoft are actively changing things at this moment. Do you want me to submit it to MS on your behalf? There's no way I can provide corroborating evidence as I've never used MP and don't realy want to start now. It would be better coming from you directly if possible. If you are quick it might even make it into the forthcoming SP1 update. Regards Pete

In the posters case some program was trying to re-connect every second, but getting invalid responses because FSUIPC was supplied with a bad key. He could check that simply by deleting his FSUIPC.KEY file, so that his FSUIPC was not (possibly illegally) registered. Not from FSUIPC, since version 3.71 or 3.72 (I forget which), as I removed all the code which was originally used to find out who the calling program was and log it. However, since only add-ons or add-ins ever use FSUIPC, you know what you have. Are you saying that without FSUIPC you get perfectly smooth operations and that with FSUIPC you get stutters? Pete