Pete Dowson

I did start to describe some of these way back in my first Controls List -- the one for FS2000, still available on http://www.schiratti.com/dowson. Those that you need and which were in FS2000 may be described for you there. Unfortunately I've never had time to develop that at all. There is now a huge number of controls, but not all of them do anything (they are either old ones which Microsoft forgot to remove or new ones they didn't get time to implement) and some don't exactly do what they seem to say they do. The only way, really, to determine exactly what they do is to test each one and see. Those that are assignable in FS's own assignments should be reasonably well documented in FS's own help system. The descriptions you see in the FS assignments dialogues are not the same as the Names, of course, but if you look in your FS9.CFG you will find KEYBOARD and JOYSTICK sections which use the control names, exactly as I list, so you should be able to relate them well enough. In the KEYBOARD sections the keypress encoding is the same as that used by FSUIPC -- you will find a table for that in FSUIPC's Advanced User's documentation. Controls are only inputs. They relate to keys, buttons, switches and joystick axes connectable to FS. They are never outputs from FS. Officially FS only "outputs" via its Gauges interface to the gauges that make up its panels (though there is also a "netpipes" interface but by all accounts it isn't good). The gauges interface is documented in Microsoft's own SDK for panel making -- in fact this is where you may also find more dcoumentation for some of the Controls. Look through the main gauges header file (gauges.h) for example. FSUIPC provides an interface for external programs to read the same sort of values that gauges can, and it also provides a lot more. FSUIPC is the general way to add on displays, but you have to be able to write your own interface program if you do this directly. There are a number of specific implementations for which display support is already provided. My own EPICINFO does this for EPIC-connected displays, as does FSCommunicator. There's software from both GoFlight and my own GFdisplay for GoFlight displays. And there are developments like FSBus and others for interfacing to other specific hardware types. In other words, if you design all your own hardware you will naturally need to look at programming your own driver for it and interface that to FSUIPC. But if you are using some already designed hardware interface you should find that the designers/makers have already done that part for you. Check the cockpit builders forums. Regards, Pete

I'm afraid this is not a WideFS "connection issue". The links those programs make to NetDir and the FlightSim folder are direct, via normal Windows file sharing, not via WideFS. WideFS only provides the link to FSUIPC, which appears to be working fine. I don't think any PM glass cockpit goes looking for a CDU or MCP. The links are the other way I think. But that's all PM stuff which you'd need to discuss with them. A "few minutes"? The log shows the Airport Chart viewer starting up at time 296065 (296 seconfs after WideClient was started on that PC), and there are no problems until time 7440809, which actually looks about when FS or something was closed judging by all the other logs. 7440809 - 296065 = 119 minutes, or nearly two hours or incidentless connection! Then there was a loss of connection for about 38 seconds (maybe you were reloading something in FS or using its menus?) after which it carried on for another 2605 seconds (43 minutes) with no troubles. The errors after that seem to be the same as on all the others. Furthermore, as the figures at the bottom show, it enjoyed a reasonable connection, probably commensurate with its demands: 8140365 Reception maximum: 25 frames/sec, 1075 bytes/sec 8140365 Reception average whilst connected: 10 frames/sec, 408 bytes/sec 8140365 Transmission maximum: 8 frames/sec, 595 bytes/sec It made 3,210 requests over the two hours 42 minutes. The one for JENNY seems to be for a completely different session -- the time doesn't match at all. There are no errors except at the end, and the program hasn't been closed when you zipped the file. REMUS started a little after GAIA and its "troubles" also occurred about 2 hours later, with pmSounds and pmRJ running without incident for that time. The sequence after two hours is the same as for GAIA, so it is probably activity on the Server interfering with the connection. Exactly the same applies to NICO, with pmRJ again running okay for two hours or so. Looking at the Server log (which, by the way, is also not terminated -- you do need to close FS so that the performance is logged), there are a couple of isolated NASTY errors: 76594 **** ERROR! Sumcheck or length fails on received socket 2876 block, len=1000 (time=0) 850015 **** ERROR! Sumcheck or length fails on received socket 2864 block, len=43 (time=0) The first was on a block from GAIA, the second from NICO. Neither would do any lasting harm, but these sort of errors should NEVER occur. They mean data is occasionally getting corrupted. I've no idea how that can happen -- it'll be more likely hardware than software -- cables, hubs/switches/NICs. Possibly sharing an IRQ would do it too. However, neither of these would have done anything noticeable. They are one-off errors and very very infrequent at that. Apart from that, the disconnections and reconnections happen at the same time as they are reported in the Clients -- i.e. after the two hours of good running. They could be due to almost anything in FS other than flight or slew modes (lengthy times in menus, delays or long stutters loading scenery, aircraft, etc. These are quite normal and recovery is quick afterwards. The whole period of such errors is a bit long though). If you were not doing things in FS when this period of problems started after the 2 hours of good flight, then I'm wondering if it is due to a memory leak problem. There are quite a few of these in FS, some fixed by the FS9.1 update. There are add-on sceneries (autogen I think) which can do it, especially if installed incorrectly it seems. If you are using FS with many add-ons it might be a good idea to search the various forums for help with this sort of thing. Regards, Pete

See the list of supported programs, above, and get the program from http://www.schiratti.com/dowson, where you will also find my other FS related programs, as well as the FSUIPC SDK. Regards, Pete

Ah! Thank you Doug. I didn't know about those. Pete

I don't know of any way to do that by ID, but you can send the FS controls for Panel 1-Panel 9 selection via offset 3110. You'll need the control numbers, which you will find in the "List of FSxxxx controls" documents availavle -- the FS2004 one is included in the FSUIPC package these days. I don't think there are any 'offsets' for that. Sorry. That's an area of FS I know very little about. I suppose if you are running on the same PC as FS you could ennumerate FS's Windows and try to identify them by window title, though that's user-definable I think. All the ClassNames are "FS98CHILD" so you can't identify them that way, and if they are undocked you have even more problems to find them. Regards, Pete

You got the PMRJDemo from PM -- PM = Project Magenta. The PMRJDemo is presumably a Demo of the RJ gauge set from PM? http://www.projectmagenta.com. If not, then I have no idea what PMRJDEMO is -- you'll need to work out where you got it from. Regards, Pete

Something is interfering with it. Check your FS Modules folder. All FS9.1 default DLLs should be dated 1st September 2004 (or maybe some other date if it isn't the US/UK edition -- but all the same date). There are 31 of them. Check, see if there are any others apart from FSUIPC. If that checks okay then I can only think there's something else running in your system that specifically affects other programs, like Window Blinds -- that is certainly one which does odd things to FS. Is there an FSUIPC Log file produced? What does it say, if so? Regards, Pete

Great! Well done! Pete

Using KeySend to transmit the signal from FSUIPC to Wideclient should work then. Just encode the keypress you need in the WideClient.ini. Don't forget to set the parameter telling WideClient to expect these things (though if you have the 'normal' PTT working already that should be taken care of). The keypress may need directing to the correct program too -- there are various methods discussed for doing that, the easiest being by getting the program (SB3?) loaded and run by Wideclient in the first place -- then it knows where to send it using the Run reference. Regards, Pete

A float64 is a double. Read it into a double, not a 64 bit fixed point number. The example you are basing it on is not a double at all but a fixed point number!! Pete

Download the FSUIPC SDK from http://www.schiratti.com/dowson and see if the information is listed. Regards, Pete

If it accepts keypresses, program the button to a KeySend in FSUIPC and program the KeySend to do the key press in WideClient.ini. See the WideFS documentation. There are examples for TeamSpeak, I don't know if they'll work for SB3. What you need to do to get keypresses into a program depends on how it is looking for them. I just don't know any of the SB programs I'm afraid. BTW, don't the Squawkbox crew or any of the Virtual Airlines provide any support on this stuff? I would have thought you'd be more likely to get help from those who already use it? Regards, Pete

Really if you don't know why you need it, then you don't need it. Develop things the other way around. Work out what you want to do, then see how you can do it. Then, when you investigate FSUIPC (e.g. through the FSUIPC SDK) you may find it useful, or you may not. But don't start the other way, saying "hmm, everyone uses FSUIPC so I shouldbut why?". Use it perhaps to help solve problems when you know the problems, not the other way around. Fundamentally it is just an interface into FS for other programs. It has grown with the additions over the years of many other facilities, mostly requested by users, but its basic function is a programming interface. That's probably because you are looking at it and trying to see where it fits rather than look at what you want to do and see what you then need to do it. Regards, Pete

Convert N from a range of -16384 - +16383 to N2 with a range 0 - 255. N is a 16-bit integer, N2 is a BYTE (8 bit). Use M as an intermediae 32-bit integer 1. Get everything on the same "base" (i.e. starting from 0): M = N (make sure you have enough room -- i.e. 32 bits) M = N + 16384 (now M runs from 0 to 32767) 2. Scale it down from 32767 max to 255 max 00 i.e 32768 different vales to 256 different values: N2 = M * (256 / 32768) or simpler N2 = M / 128 Now this rounds "off". More accurately you should round to "nearest", which would be by: N2 = (M + 64) / 128 You can do this using shifts instead of division: N2 = (M + 64) >> 7 (where >> means "shift right by"). Regards, Pete

A bit cold for the time of year, but it looks a bit better this morning. More like April than June though. Regards, Pete

I don't know what the difference is between a public PTT and a private one, but if SB3 accepts keystrokes, then just program your button to send that keystroke. Regards, Pete

You need to ask PM about this. There's no PmRjDemo with accredited access. Pete

Have you looked at the SDK? There are examples there, for several languages. Pete

I assume you are writing a program to do this? Download the FSUIPC SDK from http://www.schiratti.com/dowson. Regards, Pete

Delete the FSUIPC.KEY file in the FS Modules folder. I bet it will work then! The difference between 3.40 and later versions is that illegally made FSUIPC keys cause exactly the sort of problems you have found. If you believe your FSUIPC registration is good, send the details to me at petedowson@btconnect.com. If you disagree with any of this, check the FSUIPC.LOG. Run FS and the "traffic view board" or whatever it is, then close FS. Show me the LOG file from the FS Modules folder. Regards, Pete

Something else is wrong then. FSUIPC simply isn't doing anything until and unless it is asked to do so. What programs or add-ons are using it? (Why did you install it?). There are also some by now well known reasons for this -- one is a bug in an earlier version of FSNav. If you have FSNav installed, check that you have the latest update for it. Active Camera also needs an update for FS9.1. There may be others. Regards, Pete

Well, not deliberately sarcastic, more completely and absolutely frustrated because I cannot explain any better how to find the Announcements. They stare you in the face at the top of the forum every time you come here! I cannot understand how you manage to get to see my replies! How do you do that? Tell me how you managed to enter a message here and see my replies, yet still cannot see the list of messages from which to choose? Is this a sort of selective sight resulting from autism? If I understood that then perhaps I could help further! I really cannot see how to help unless I can understand what you are seeing so differently from every one else who visits here. The instructions to get yourself flying were nothing to do with finding a simple announcement. I only referred to the announcements because it is those which tell you what versions of the programs to use. If you know how to find out that simple information then you'd never have the same sort of problem again, so it is my way of helping you work out how to solve your own problems from then on. The only thing you need to do to fly in FS9.1 with FSUIPC is go get the latest FSUIPC from http://www.schiratti.com/dowson and install it into the FS modules folder. This is what I said several days (?) ago, thus: Regards, Pete

Oh dear, this is a first! How can you not see the list of messages in this Forum? How do you find my message in order to reply to it? :roll: I said "Top of this Forum", meaning the first few threads in this Forum. Exit this message and look up the list of messages until you reach the very top. The first three are Announcements and the next four are Sticky -- they are clearly labelled as such in Bold. In particular the third announcement is: Announcement: List of current supported versions [25th April 2005] and this is the one I referred you to, just to find out that the current version of FSUIPC is 3.48! :cry: Pete

That's a real puzzle then. I'm sorry, but I think you have to look to the software in the PDA. Did you prove to yourself that the FS PC end was still sending? That is easy enough with PortMon. No. My abbreviation "RMC" stands for "GPRMC". The GP ones are all the standard NMEA-defined ones -- I just left off the standard "GP" part in the parameter definition for the INI file. The "PGRMZ" one stands for "Proprietary Garmin sentence Z". I don't know the prefixes PFSR, LXWP and so on, only the GP ones and a few of the Garmin ones. Regards, Pete

No, sorry. It is unlikely to be stopping from the FS PC end -- there's no flow control in GPSout, it simply keeps sending stuff. You can check that with "portmon" (a free utility obtainable from http://www.systeminternals.com). Run it before FS. Maybe there's some restriction in the PDA software? What sentences are you selecting in GPSout? If you have too many selected 1 second may not be enough time between them. The 4800 speed works out to 480 characters per second max. You need a good gap between them, so say 400. With an average sentence length of perhaps 60-80 characters that only allows 6-8 different ones. Even then things might get clogged up in the PDA. Try (1) increasing the time from 1000 to 2000 or more, and/or (2) only one or two sentences at a time. Do you know which sentences your software is expecting and needing? Regards, Pete