Pete Dowson

FSUIPC sees the hat switch as 4 or 8 separate buttons (depending on the device) -- so you can program them in the Buttons tab. If you want to use it in virtual cockpit mode exactly as it defaults in FS, however, you'll need to enable it in FS. FSUIPC doesn't support such a "POV" (point of view) control in the way FS does. Pete

The pedals won't affect the PARKING brake. If you mean your toe brakes were full on, then that is certainly more likely. Most pedals have the brake axes reversed. You'll need to reverse them in FSUIPC. Have a look at the Calibration screen in the options -- you'll see the checkbox to check. Regards Pete

Unfortunately neither log is of any use because of this. The client log shows PFD loading and everything running perfectly well -- for just 15 secoonds before you close it down. I hardly think 15 seconds is enough for PFD to get going properly. Even so an average frame rate of 25 is good, very good, and the PFD program made an average of 65 requests per second. The Server log is totally irrelevant to the above, of course. It simply shows an FS session runninmg for 18 minutes, with the Client (ORD12) apparently restarting at irregular intervals. Since there's no matching client log there's no way of knowing why. It looks like you did it manually in some cases. The first connection lasts for about 1 minute into the session for about 5 minutes with no problems, reconnecting only 8 seconds later. It lasted another 4 minutes then disconnected and reconnected a good 1.5 minutes later, this time for only 40 seconds. And so on. Whilst connected the performance was good, 24 frames per second, but of course it wasn't connected much. There's no other information I can extract. The client log would show more. Pete

Yes, I did link it to this thread. :-) Best Pete

Hi Chris, I received this reply over in the PM webgroup: Looks like I should simply warn folks off Windows Server in my WideFS documentation? What are you using on the FS PC, by the way? Regards Pete

Ahnaturally I'd assumed that WinXP SP2 came with such already installed. After all I think it does have some sort of speech stuff in it. In any case I only wanted to see what it did. I have no use for it at present (I use a fully switched cockpit setup), though possibly I could use in with a headset for selecting Radar Contact actions (i.e. replying to RC by voice instead of buttons). I'll probably investigate that at a later date. I did try the commercial "Voice Buddy" program for a while, but it was too inconsistent and got me into deep trouble with ATC several times! ;-) Regards, Pete

Even stranger then that the author would ask me for an Access Key for "SpeechBuddy" this June! I'm thinking now that maybe the one he has a Key for is actually a LATER version -- i.e. #3 -- but that he's not "Open Sourcing" it, possibly preparing for a shareware or payware release? There was no version number associated with the details he sent me. In case this is what is happening, I cannot supply a Key for version 2 until I hear from him that this will be okay. He may want to encourage folks to move on. I have written to him on the address he used in June and hope to get a reply some time ... Regards Pete

Hi again, Okay, I have researched this and seen what it might be able to do (though on my system it gives OLE errors). Then I remembered -- the author did request and receive a Freeware FSUIPC Key back in June 2006. But it was for a "SpeechBuddy" not a "Speechbuddy2" -- so the key he received then, and actually built into the program, would not be applicable to the renamed one. I believe some of the other details (in the Version Info) have also changed. I'm not sure what his intentions are with SpeechBuddy2 as he didn't request a new key, so I have written to him too. It is easy enough for me to make one, but I think it should be built into the program, as the previous one was. Incidentally, were you using Speechbuddy before Speechbuddy2? Regards Pete

What's "prm"? Midnight where? Are you talking about Zulu time or local time? The only day I know in FS is the Zulu day. It is well known. There are lots of time zone issues in FS. this is why FS Real Time is so popular -- I use it, and it works well. The downloadable Zip includes updated BGLs (scenery files) too, which correct some of the zoning errors. Er, what a cheek! Why don't you just remove FSUIPC and find out for yourself? Or read the documentation, which describes everything asbout FSUIPC -- the ONLY time-related option (which would need to be user enabled) is a seconds-level synchronisation, that is all. FSUIPC is not an application program, and in any case why should it deliberately mess up time zones and differences for you? I rather resent your implications! Well, a suggestion: go and get FSRealTime and pay the author some money for it, for a good job! I think you'll find it on Avsim. Pete

Er .. autorudder just means you can "steer" with the ailerons -- it's for folks with no rudder pedals. It provides auto-coordination of aileron and rudder in the air, and operates both steering and ailerons on the ground. It makes your rudder pedals rather redundant, if you have any. There's no way that will switch a rudder control to a spoiler though! ;-0 Pete

Okay, I've downloaded some files to look at, but I'm not sure when I'll get time to sort through them to work out what the program does, nor why it needs to use FSUIPC. Unfortunately the web site isn't very explanatory. I read it and I still have no idea what it really does, nor why it needs to do any more than convert speech to keypresses or similar. Can you summarise? Regards, Pete

Possibly. I don't actually know of it. Could you provide a reference so that I may see it please? Are you sure it uses FSUIPC? I'm not sure why a speech-to-keypress, or even speech-to-FScontrol (whichever it may be) would need to use FSUIPC in the first place? I would need Version information for it in order to make the key. I can take a look if you supply some details, otherwise I'd need you to find them out for me. I see you are asking the author about FSX as well. Can you tell me what is FS-specific about this program? As noted above I am having difficulty imagining what it could do that needs FSUIPC or is FS-version specific. Regards, Pete

Sorry, I've no idea how you managed to do thatFSUIPC has facilities for swapping axis uses according to aircraft name, but nothing checking "on ground" or not. I'm pretty sure PMDG don't support any such facility either, so I'm afraid I just don't know how you did it. Regards, Pete

You give insufficiient information I'm afraid. Are you using an offset, or a control, or what, to control the flaps. And how? What does WideFS have to do with it? FS will never change the flap setting on its own, though it is conceivable that an add-on panel may do so -- so test with default aircraft only. Have you tried using the Logging in FSUIPC to see if you can trap whatever it is which is doing it? You can log both axis and button type controls, and you can Monitor offsets. Not knowing anything about how you are trying to control the flaps, I'm afraid I cannot advise further. Regards, Pete

Yes. "Float64" means "floating point 64 bit". It's the unit name used by FS in the same FS SDK that the Names and the Token IDs come from. That'll all be revised -- the whole of that second table will be deleted, most of the values moved into the main part. This is thanks to support for those being made "official" by Microsoft in FSX. Since you are using the SDK (which isn't from "my site" BTW, but from Enrico Schiratti's "Dowson" page), you should also have found in there the program called "FSInterrogate" which not only shows you all these values, live, but also enables you to view them all in all supported formats, including "float64". Additionally, you may like to look at the Logging options tab in FSUIPC options. On the right-hand side there's a facilitiy to monitor any offset, and again one of the units you can choose is "FLT64". These facilities are documented in the Advanced User's guide for FSUIPC. When you are investigating values you can get from FS it is useful to know about these things. But "size" is a relative term. For example, just 1 64 bit floating point number is actually 8 times longer than 1 8 bit integer ("byte"). For all I knew your line for "SIOC" may have been using bytes, words, double words or 654-bit values -- all are valid units. If it needs size in bytes, then you need to know that the size is determined by the type of value: FLOAT64 is a 64-bit floating point value. 64 bits is 8 x 8 bits, so 8 bytes. There's NOTHING else in "this". It's a 64-bit floating point number!! There's only the 64 bits of that number in it! Your question makes no sense, sorry. I'm afraid the FSUIPC SDK is aimed squarely at programmers. That's what "software development kit" means -- a kit for programmers doing software development. From what you say it seems to me that this "SIOC" stuff must also be aimed at folks with some technical experience? Or is their documentation just not up to scratch? Please take a look at the tools I do provide. Play with FSInterrogate for starters, look at the various values it reads. I'm sure you'll learn a lot. It isn't just that list -- browse through the values in the main list. There are plenty of "double" floating point values there too. and some of the values in the "FS2000" list are BOOL (32-bit), BOOL16 (16 bit), SINT16 (16 bit), etc. The list is simply one derived originally from the Gauges SDK for FS2000, to which some offsets have been mapped. As I said, I'm integrating most of those into the main list. But this won't change what sorts of numbers they are. Regards, Pete

Supported, now, actually. I thought they were among those I moved to the first table? If not they will be in the next update. There's quite a lot of "unsupported" data which is being provided by FSX via SimConnect, so I can safely assume it will be okay for the foreseeable future. ;-) Yes, the double floating point value at 2834 is what you need. I don't know what that is supposed to mean, but if you are trying to read it as a 1 byte integer you will get it wrong. It is an 8-byte (64-bit to be precise, floating point number, a "double" in C/C++ terms). It is listed of course -- 2866 is part of the 8-byte (64-bit) value at 2860, the "hot battery bus voltage". You are not reading the list correctly at all I'm afraid. You are simply taking a small part of a large number. Again, I've no idea what your size of 1 means, but 2866 isn't an offset of anything at it stands, but part way through. All those variables labelled "FLOAT64" are 64-bit floating point numbers, at the offsets given. I'm afraid I cannot predict what you will get if you take small bits of 64-bit numbers! Regards, Pete

Sorry, there are no sound facilities in FSUIPC. I think you need to ask the PSS support folks what can be done. I don't really understand much of that, but it does really sound more like the panel you are using is simply designed to prevent external controls being used. Have you asked their support about these things? I really cannot see how I can provide more than the generic facilities I have done -- Iam really not in the business of doing specific drivers for specific products. Maybe PSS ought to look at supporting folks with hardware? Regards, Pete

There's no such variable nor offset in my software. There is an assignable control provided which simply toggles or sets some bits in PM's offset space. The rest is then up to PM. Please refer to the PM offsets documentation on the PM website. You can verify the correct bits or values are changing via the MCDU offset monitor, or FSUIPC's own monitor (set in the Logging options). Please report PM problems to PM support -- I really cannot deal with other folks' software here. An that's especially true for the AB offsets which I've never even used -- I don't have any of the AB software. Regards, Pete

Hi Chris. The logs you attached were of no use. Well, the 6.47 one was okay, but the 6.70 one is not comparable because you only had "Log=Yes" for that. Here's what i said: "Perhaps I could compare the Logs -- but use Log=DebugAll, not "Yes" as you did before -- that only shows the exchanges between client applications and WideClient, which were fine. Do exactly the same test with 6.47 and then with 6.70, Zipping up each log separately and labelling them appropriately." I was going to spend some time on this today, but I need something to start with, please. Don't attach them here, send to petedowson@btconnect.com. Regards Pete

Why would that be of interest? Using WideFS is not at all dependent upon having an FSUIPC key. If the time was being spent in my code, in Wideclient, then it would be a doddle for me to find. It would even be reasonably easy to find if it were reproducible on any of my 10 PCs. But is isn't either of these things and in fact is a very very rare occurrence. The only place in the processing it can be sepnding any time is in Windows -- probably in the Network drivers themselves. Something is locking up at such a low level that the normal Windows message processing is very slow. Again, also unfortunately, there's been very little change in the way WideFs uses the Network software in Windows -- the main differences being the addition of UDP and the broadcasting by wideServer so that clients can find servers automatically. Are you using WinXP on both machines? If so could you please just try without an INI file at either end? Just let everything default. I'll look at the Logs later, but probably tomorrow now. Regards, Pete

Hmmthere's a couple of years of development between the two, so that's really not a lot of help in itself. Perhaps I could compare the Logs -- but use Log=DebugAll, not "Yes" as you did before -- that only shows the exchanges between client applications and WideClient, which were fine. Do exactly the same test with 6.47 and then with 6.70, Zipping up each log separately and labelling them appropriately. Maybe if I can find some intervening release versions we can zero in a bit more -- I can see 6.65 (June 2006), but for anything earlier I'd have to delve into archives. Version 6.50 was the last major change before that, and that was August 2005! If you ignore this 100% business (it may or may not be relevant, i don't know), does it work? just saying "100%" isn't helpful. Here 6.70 is working flawlessly on many systems, using a mix of TCP, UDP and IPX. It's easily the fastest version, very smooth for gauges like those in Project Magenta. But evidently there's something it does to achieve this which isn't compatible with, what a handful maybe of systems. Why, I've really no idea at present. Regards, Pete

There you have it then. It couldn't be much clearer, could it? It is telling you what is wrong. EFIS98 was designed for FS98, and it did even work in FS2000, but it looks like the author has deliberately stopped it in FS2002 by checking the FS version. Version 3.10?!!! The current version is 3.70. I cannot support 3.10 in any case. Please update if you want more help. In any case there is nothing wrong with either the connection to FSUIPC or FSUIPC. Here: You need a change in EFIS98 to bring it up to date for FS2002 (which is itself already 5 years old -- EFIS98 is about 8 years old now). The author never developed it further. He did work on a much more sophisticated system based on B777 autopilot and FMS operations, but that never got issued. I think you may need to seek alternatives, or go back to FS2000. Regards Pete

No it isn't. In jorge's case the connection is working perfectly, but something on the client Pc is preventing correct multi-tasking so that ASV6 isn't getting past the initialisation. All of Jorge's WideFS logs show the wideFS side working perfectly. In your case this is not occurring. You have a non-working connection. completely the opposite. It looks like it isn't working because it is continually restarting! WHY have you changed the AutoRestart value from its default? Maybe i should delete that parameter as, especially when you first connect, there's so much being done 9programs loading, initial data exchanging, etc) that it is quite possible for the frame rate to be less than 5 for 5 seconds. But why have you changed it? In all cases if you have a problem, try reverting parameters to defaults. All the stuff has been "tuned" over many years and should really be left alone except under instruction for special cases. It doesn't want to use IPX. you are reasding it wrong. The server always sets up services for TCP. SPX and UDP. It will retry all three each time it initialises. Pete

Jorge, I received the "DebugAll" log, and this shows ASV6 connecting, but then simply looping on the initial operations -- the part in the FSUIPC_Open call it makes when it is establishing the connection. It is reading the validity check (okay0, and the version numbers of FSUIPC and of FS okay. But it simply loops on this, retrying every 2-3 seconds. I really don't know what it is doing -- I assume it is timing out, which means it is not getting the response back in sufficient time. The actual time spent in Wideclient in that period (3 seconds), to actually process the request, is only 1-10 mSecs in most cases. Something is stopping ASV6 getting the process sufficiently, so it isn't processing the messages. This, combined with your 100% utilisation observation seems to indicate a PC system which is simply not coping. Whether this is due to other processes or just a slow processor i am afraid I don't know. Did you tell me what system you use (processor, memory, windows version and so on)? What is your typical FS frame rate? Do you have the FS frame rate limiter set? The WideFS link is flawless and the exchanges are perfect. The problem lies in the client PC somewhere -- something is preventing correct multi-tasking. Regards, Pete

This shows a healthy connection to FS, and the fact that there have been 2 transmissions back to the FS PC every second ON AVERAGE (max of 17), means that ASV6 or something is actively sending and receiving data. It looks like you did not have Log=Yes for this test, so apart from the good performance nothing else is useful in this log. Please enable the data logging. If you don't mind making a huge file, use "Log=Debugall" -- but for me to look at that you'll need to ZIP it up and send it to petedowson@btconnect.com. How do you know they aren't relevant? Did you try killing them? I couldn't possibly hazard any guess without such a trial-and-error process! something in your system is evidently interfering with WideFS, you need to find out what. Pete