Pete Dowson

You can get USB serial port adapters for $20 or so. In fact they work better than real COM ports, so much so that I'd recommend using one for the PFC gear and leave the real COM port for the less arduous GPSout tasks. Pete

The requests basically follow the same format as the requests put directly to FSUIPC, as defined in the .h header files in the sources for the libraries in the C parts of the FSUIPC SDK. They used to be identical, in fact, but I decided that was a waste of space (Adam Szofran used whole DWORDs for things only needed a byte or word, for example). Also I extended the command set. The blocks are easy to decode once you realise the structure if the FS6IPC structure , or derived from it. The codes used at present are as follows: // IPC message types #define FS6IPC_READSTATEDATA_ID 1 #define FS6IPC_READSTATEDATA_ID_NEW 0xfe #define FS6IPC_READSTATEDATA_ID_SHORT 0x1001 #define FS6IPC_READSTATEDATA_ID_NEWSHORT 0x3001 #define FS6IPC_READSTATEDATA_ID_NEWNEWSHORT 0x7001 #define FS6IPC_READSTATEDATA_ID_COMP 3 #define FS6IPC_READSTATEDATA_ID_NEWCOMP 0xfc #define FS6IPC_WRITESTATEDATA_ID 2 #define FS6IPC_SPECIALREQUEST_ID 0xabac #define FSUIPC_COMPUTER_NAME_ID 0x1002 #define FSUIPC_EXTRA_DATA_ID 0xed Some structures new in WideFS compared to FSxIPC are: // read request structure typedef struct tagFSUIPC_SHORTREAD_HDR { union { DWORD dwOffset; // state table offset, high byte = ID BYTE bBytes[4]; } Id; WORD sBytes; // number of bytes of state data to read } FSUIPC_SHORTREAD_HDR; // write computer name structure typedef struct tagFSUIPC_COMPUTER_NAME_HDR { DWORD dwId; // FSUIPC_COMPUTER_NAME_ID DWORD nBytes; // number of bytes in name string following } FSUIPC_COMPUTER_NAME_HDR; There are probably others, but I'd have to ferret them out. They should be easy enough to follow given all this though. That's there already. Aren't you seeing it? The DebugAll logging includes pretty much everything, there are separate options. Pete

Hmmmif RC is actually running okay except for this apparent delay, could that delay be in the spoken response you are expecting rather than the action RC is taking? In other words, maybe there's a problem with the sound subsystem? Try shutting FS's sound off (Q) to see if that may be related. Maybe changing the sound acceleration in Windows may help (e.g. turning it off). I really have no experience of ever trying to run things on the same PC as FS except with hyperthreading PCs (P4 3.0 GHz or better), where there certainly is no problem. The symptoms you describe seem most odd, though, as you say somehow dependent on some common resolurce, as I'd expect setting RC at a higher priority than FS to cause some about of jerky behaviour in FS. Could it be a memory capacity problem? How much memory does your PC have? (What processor is it anyway? Achieving only 20 fps with all sliders low it sounds rather underpowered for FS2004). Regards, Pete

On the contrary, if the stutters are shorter when the transfer speed is higher, that indicates that the programming in PocketFMS is rather assuming no other processes are running when it is receiving data. It should be using overlapped I/O which allows the data to accumulate independently of program action instead of looping for each character without relinquishing control. If the stutter was due to graphics updates then they would be the same no matter what speed of transfer were used, as the update of the graphics would be independent of that. Regards, Pete

How odd. All that happens with the keystrokes is that they set a flag inside FSUIPC which is read by RC on its next scan. No, I am quite sure that is an incorrect interpretation of what you are seeing. The same will probably occur whenever you do something which takes the processor away from FS. Advdisplay is not at all involved in anything to do with keystrokes, it is merely a passive display window -- but right-clicking puts FS into a menu mode which stops a lot of its other activity. I think that something is really very very heavily using the processor (you ARE running RC on the same PC as FS I assume?). Maybe you have FS's settings turned up rather high for the power of the video card and main processor, and RC is not actually getting to run very often? Try limiting FS's frame rate (Options-Settings-Display-Hardware I think). Reduce it to something low to start with, like 15. If that helps, increase it until you get problems, then reduce it a little. This sort of thing is really quite important whjen trying to get things to share the processor well with FS, which otherwise wants to use it 100%. If you have a dual processor system, or one with Hyper Threading then it shouldn't be necessary. Regards Pete

Add parameters to FSUIPC.INI, as described in the Advanced User's documentation under the heading "Programs: facilities to load and run additional programs". Have a look, come back if you have any questions. There's a utility called RunOptions by Jose Oliveira also which may help -- see http://www.schiratti.com/dowson. Regards, Pete

No encryption, but a very simple compression is used -- replacing multiple copies of the same value by a count, with a special escape value. Don't remember what it is though. Maybe hex AA. You can use "Log=DebugAll" in WideClient to log almost everything and see the data as it has been received and how it expands. Should help. The logs can get pretty big quite fast, mind. Regards, Pete

Well, it is internally, yes, but most of what it does is automatic and doesn't worry you. Otherwiese it is only a collection of little, easier, things which you choose whether to use or not. No. When it is installed into FS it runs automatically. you can forget it is there. Everything described in the documentation. Before laying out good money, why not just download the FSUIPC.ZIP, and pull out the User documentation. Read through it and see if you really want to spend the money. Regards, Pete

It should do as far as i know. Can you contact the author, Dave March, about this? He's very helpful and should be able to sort it pretty quickly. Regards Pete

At what point in the loading progress bar has FS reached when this occurs? Could it be in the "Loading traffic" section near the end, by any chance? I have found that the AI traffic loading can be very touchy when the traffic is very heavy of complex -- My Traffic, for instance, gives me more crashes at that stage then, for example, Ultimate Traffic, even with the same % settings. With My Traffic at 100% FS sometimes even crashes during initial loads, way before WideFS is even active. I had to turn it down to 65% Try reducing the AI traffic percent -- you may find a level where FS is more reliable. HJave you not simply tried pausing or closing WideClient's applications instead, after all WideClient is only acting on their behalf. I see you are running FSRealTime & ASV6. Of these two the most likely cause is FSRealTime, if you have it set to update the time too often, for instance, and it tries to do this whilst FS is loading new Traffic. This is quite a well-known problem and mostly was fixed by changes in FSUIPC (make sure you are using FSUIPC 3.53 or later) and some improvements in FSRealTime -- make sure youy are using the very latest version of that. Aha! No it wouldn't, but if you are using an add-on AI traffic system then possibly you removed some aircraft which have AI duties? After changing aircraft you usually need to regenerate the traffic files, especially with Ultimate Traffic, which I think uses all the aircraft it finds suitable. Regards Pete

For such an old program I can possibly make one, but I need these details: 1. The EXE program name 2. The Product name 3. The Company name. For the last two, right-click on the EXE in Explorer, select Properties then Version, and look for those two fields. If they are not both there, look for "Program Description". I need any two from those three. If there are not two of those for me to use, then I'm afraid I cannot make a key and you will have to purchase an FSUIPC user registration. Regards, Pete

There is another case where multiple copies of running versions of FSUIPC may be detected, and this is where a previous session of FS has been closed, and appears to have closed successfully, but is in fact still running. Such cases are caused by some errors in add-ons -- an early version of Active Camera did this, for axample. It seems that some DLL's create threads which fail to terminate, and the whole process remains in memory, INCLUDING FSUIPC. No sign of FS appears on the desktop, but it is still there -- a visit to the task manager (Ctrl_Alt_Del) and its Process list will show the FS exe. If this happens again, check that process list, and delete the FS process before running FS again. Then look for the culprit add-on causing the hang on termination. Regards, Pete

All I can think of, it is was FSUIPC, is the Monitor facility, on the Log options page. The elevator trim value is available in two forms: Offset 2EA0, type FLT64, units radians (-ve down) Offset 0BC2, type S16, -16383 to +16383 Pete

I hope you are using a very powerful PC or one with HyperThreading, as running another separate graphics program alongside Fs in the same Pc is asking for jerky behaviour otherwise. Sounds like the PocketFMS program is not so good at using overlapping I/O and is hogging the processor which reading each byte of the incoming message. It is either bad programming on the COM port end, as just mentioned, or, yes, a graphics thing. For the former try (1) the highest possible speed accepted in the PocketFMS settings and (2) the minimum number of NMEA sentences which work to give the data it needs. For the latter I'm afraid I've no solution otherthat a very fast video card and dual processor or hyperthreading. Regards Pete

FSUIPC has absolutely no knowledge of what video system you have, nor does it need to know. the registration is held in a file called FSUIPC.KEY in the FS Modules folder. If that is still there are staill the same then it cannot become "unregistered" unless you re-installed windows or rolled back to a copy of the registry pre-dating your original registration. In either of the latter two cases, just re-register with EXACTLY the same information as before -- cut and paste it from the FSUIPC.KEY file (which you can open in any text editor) for ease and accuracy. You got something wrong, then. Your name and email must also be EXACTLY as originally entered! No, that is entirely irrelevant. No, the registration is tiued to the ORIGINAL name and email, not any new one. Yes, just enter the details correctly. Also, please update to FSUIPC 3.53, the only currently supported version. your 3.48 is well out of date and is not supported. Pete

Neither are relevant, as all GPSout does is throw standard NMEA sentences out of the Port you specify at the speed you specify. Nothing more, it is very very simple. Go to http://www.systeminternals.com and get PortMon. Use it to check that the data is going to the port. Everything after that is to do with your cable and device, or its software. Regards, Pete

There's no chance at present. I just don't have time to do the documentation (for that's all there would be). Sorry. Last time someone did this for an Apple or Linux PC was years ago, and he just analysed the data streams and asked the odd question now and then. Things have changed a bit though since then. Regards, Pete

In the user documentation for FSUIPC version 3.53 there is a boxed warning about FSUIPC and FS2000. It does tell you how to work around this problem -- which otherwise I have found no solution for. Please try it. Regards, Pete

Just pull up the GPS on your FS screen and compare values. I really cannot do more than that. Yes, this is what GPSout is doing, and it gets the track from the GPS and corrects it to TRUE using the current MagVar. Early versions of GPSout did provide track computed approximately my own way -- from heading and wind vectors, but this was in error on occasion. The GPS values have given excellent service according to all those who reported the earlier discrepancies. Regards, Pete

There's a misunderstanding there. FSUIPC injects nothing at all into FS9. That is all done through the multiplayer interface, it is nothing to do with FSUIPC. What may be injected into FSUIPC's "TCAS" tables, for reading back by TCAS gauges and the like, are details of the same traffic that is being sent via MP to FS. This used to be done by Jose Oliveira's "AIBridge" program for SB2 but I suspect SB3 has it built in now? I don't know about the IVap programs I'm afraid. I don't know how your program is reading data with "regular multiplayer", sorry. All that side of FS is a complete mystery to me, something I've never dealt with. The FS DLL "TrafficInfo" only deals with AI traffic I believe, and that is all switched off when Multiplayer is enabled. If your TCAS display is reading FSUIPC's TCAS tables then the traffic has to be injected into those in the first place. I don't know what program you are using for this, but it sounds like you need to find out what part does what and then ask the author. Maybe you aren't running a crucial part of the total package? I'm afraid I cannot advise any further. I don't have any of these programs. I hardly get time to fly off-line let alone try my hand at on-line flying, though I would certainly like to, one day;-) Regards, Pete

Sorry, I just couldn't read all of your single extremely long paragraph. Please, next time you write to me try to break it up a little so it is readable. Your problem sounds like one already covered here in another thread. I think it turned out to be video driver problems. Certainly, if it is AdvDisplay that concerns you (you don't actually say anywhere, I had to guess) there is nothing in it which can have those effects -- it is all a video driver problem. I'll see if I can find the other thread. Stand by ... [LATER] Right. See these threads: http://forums.simflight.com/viewtopic.php?t=47479 http://forums.simflight.com/viewtopic.php?t=46795 The second actually showed a solution found, thus: I don't know if that will apply to you, but certainly either a change of video drivers or finding better settings will fix it. I think you are just on the edge of the cards capabilities with your settings and adding one more Windows takes it over the top. Regard Pete

What version of GPSout are you using? That was changed a long long time ago! Track (TRUE) is provided in RMA, RMC and VTG Heading (MAG) is provided in VTG Track (MAG) is provided in AV400 In Fs2002 and before the track has to be computed from heading, ground speed and wind vectors, so it may not be so accurate. In FS2004 GPSout obtains it from the GPS values -- the track will be the same as that shown in FS's own GPS. Regards, Pete

FSUIPC doesn't use Networks at all. You mean WideFS. WideFS isn't making folder-to-folder connections at all, it is using the TCP/IP or IPX/SPX protocol to talk across your Network -- program-to-program, not program-to-file. The other things you mention are all to do with Windows Explorer and its file sharing facilities. I'm afraid that's an area I know little about. I use it of course, but I'm stumped if it goes wrong. I did run across problems recently with "too many connections" failures in Networked file access. It seems that Windows XP is deliberately limiting how many connections you have to to any one PC. It is up to 5 with WinXP and 10 in WinXP. It seems if you need more connections to the file system that that you have to buy Windows Server. If you have mapped folders or drives, then each may represent at least one connection -- I don't tend to use them much, I just point the program to the folder via the normal explorer-type views. Then the connection is only counted whilst it is being used. Regards, Pete

Thanks Hugo. However, I think the latter is usually the problem. you can't easily change a DLL which is in current use, and most of the common Windows DLLs are in constant use -- the desktop and Explorer use them. This one might be an exception, I don't know -- it depends what is running I suspect. You don't need to go far to find an assortment of different versions of COMCTL32.DLL. I searched my own C: drive and came up with 6 of them, of 4 different versions. I think some of the Windows XP updates replaces that DLL. I notice also a COMDLG32.DLL and wonder if that may have something to do with the reported problem too, though I think it used to be only COMCTL32.DLL which was replaced by some video driver installs. The problem with the DLLs downloaded from the site you gave a link to is that it seems to have only one version of each and doesn't say what they are for (e.g. what operating system, version and so on). I just looked at the COMCTL32.DLL on the DLL site and it appears to be older that all 6 of those on my system. Regards Pete

I did it! I used the long way round -- uninstalled everything I could find dealing with BlueTooth. then installed the stuff from the manufacturer's CD (Belkin it was) -- but this time I did NOT plug in the bluetooth adapter first! I think that was the problem last time. It got very confusing. This time I refused to put the adapter in untill all the software was installed, THEN plugged it in and followed the instructions to point it to where the drivers were. ... and it works! Well, it talks to my mobile phone and to my mobile phone headset (provided the mobile phone isn't already connected to it!). I could use the little mobile phone headset (light, comfortable thing clipping to the ear) for ATC, if I ever fly on-line! All I need now is a Palm with Bluetooth! ;-) Thanks! Pete