BrunoBL

Pete, Yes, I am running my application under WideFS in another PC, to free the PC running FS from other chores. So if I read things like airspeed, altitude, geographic coordinates I should expect a lot of traffic (not only the FS-related FPS issue, but traffic over the network as well), as opposed to things like fuel levels, flap and gear setting, etc, which will probably not change on every frame. Regards, Bruno

Pete, Good to know for sure that it is not the reads that may affect performance. I imagined that this could be the case, and was already doing all the reads before calling one FSUIPC_Process after the last one. In my program all this actually happens in a loop, so I am calling a FSUIPC_Process once in every cicle. From the above, I assume that if I expect a too frequent refresh rate in my program (now at 500ms), this could in fact degrade FS performance. Due, not to the rate of reads as I had implied before, but rate of FSUIPC_Process. What is left to be determined (by trial and error?) is whether or not 500ms is a reasonable interval for repeated calls to FSUIPC_Process in a loop. Best regards, Bruno.

Pete, Sorry if this has been asked before. I have been playing with FSUIPC and Delphi to do some reads (and a few writes) into FS. From your replies to a number of people here, I understand that FSUIPC won't by itself do much of anything unless asked to do so by some application. I coded a program in Delphi which runs in another PC and talks to FS via WideFS/FSUIPC. The Reads are within a loop (a Delphi timer) and the writes are done on the fly after pushing a switch or something like that (to avoid unecessary Writes inside the loop). So... is there a practical limit to the number of different offsets I Read or Write before advesely affecting the FS perfrmance? Of course this may depend heavily on processing power, available memory, efficient coding of the guest application, etc, but I wonder if there is a ballpark figure for a limit to this. Are we talking about a dozen offsets? Tens? More? Also, since my application doesn't care much about precise timing (I am displaying radio frequencies, NAV radials and lighting up external LEDs and lights), I am using a relatively large time interval between loops (500ms). Am I correct to assume that a tighter loop, so to speak, would request more reads and thus contribute to degrading FS performance? I fugure that FS has only 40ms to do everything it has to do between screen refreshes if it is going to run at, say, 25FPS. That is why I chose my timer to run at a (I hope!) conservative 500ms. Thanks for all your educating replies here. Best regards, Bruno.

Sidenote: I evidently failed do intrerpret correctly your explanation. After editing FSUIPC.INI (with the working example as in the previous post) I went back to FSUIPC from inside FS, only to find the "PM GC controls (by param)" facility, just as you described. I was looking for (gues what?) the wrong entry, under "PM ND Range". All cleared up now. Best regards, Bruno.

Pete, Finally I found (thanks to your indication!) reference to control 2999 in the advanced users guide (under Project Magenta Controls). It mentions, amongst others, parameter 40 for a 5NM range, and 47 for 640NM. At first I thought of using a "set" for the ND map range in the control pulldown menu in the FSUIPC keys tab (and pass the 40 and 47 parameter), but there were only Inc and Dec commands or discrete values from 10 to 320. So I included the following in the FSUIPC.INI keys section (assuming, for instance, a "T" key for 5NM range and "U" for 640NM): The above worked and now it is just a matter of generating the required characters with the KE72 keyboard encoder. Thanks again for the precious information and for bearing with yet another user with more of the same questions. Best regards from Brazil, Bruno.

Hello Pete and all, I am using FSUIPC with Project Magenta and a Hagstrom Electronics keyboard encoder. At this stage I can retract or extend FS's landing gear with a "real-world" gear lever, and I wrote a Delphi program to get FS's wheel position and light up external wheel in-transit or down-and-locked lights. To boot, the program calls out "1000, 500, 400..." etc during approach. Neat. Now I plan to read (with Hagstrom's KE72) the individual positions of rotary switches and send them to FSUIPC as key presses for various uses, one of which is the setting the ND map range. From PM's manual I learned that there is no discrete keypress for the two extreme Boeing ND map range settings (5NM and 640NM) although PM does support individual key presses for all other map ranges (10, 20, 40, 80, 160 and 320NM). I questioned the PM team about this and they confirmed that indeed there is no direct keypress for the 5NM and 640NM ranges, but they also said they may set by parameter with FSUIPC and the PM offsets. Looking at their documantation, I find this reference: But... I cannot imagine how to use PM offsets from FSUIPC. Worse, I don't know how to uses the parameter feature in FSUIPC. I must be searching in the wrong places, because I could not find anything related to this in the documentation. So... how can I make FSUIPC talk to PM's offsets and thus select the 5NM and 640NM ranges in the ND map using discrete keypresses from the keyboard encoder? Any help would be, of course, very welcome. Thanks for your patience, Bruno.

Jwenting, First, please note that my previous reply was in a passenger-entertaining context, *not* a navigation (or even situation awareness) tool. In fact, GPS does give out altitude information (provided at least 4 satelites are in view). Nonetheless, altitude accuracy is poor (150% of the horizontal position error IIRC), compared to the expected GPS accuracy. A real-world position accuracy of, say 50 ft would yield a vertical accuracy of around 75 ft. The real trouble would not be altitude, but *attitude*. GPS receivers have no way of determining the aircraft's attitude. Any system designed to feed a virtual "external" view into a display would necessarily get data from the a/c's IRS, ASI, or whatever. But this is not necessarily illegal (in the context of the previous passenger-entertaining scenario), given that the passenger-cabin moving maps, for one, already get data from the a/c's navigating system and are installed in almost every modern airliner. The question is not whether or not this would be legal, but how much it would cost to certify. And, of course, if the manufacturers would find this idea as appealling as the passenger-cabin moving map was. Having said all that, I have read in the past (10 to 15 years ago!) that a navigation equipment manufacturer (Honeywell, I think) was researching just that. A virtual out-the-window view which would map (or project, if you will) a navigation chart into a database of terrain elevations, producing a 3-D view of an area chart, for instance. This never made the market. I wonder why. Regards, Bruno.

I think that this kind of 3-D visual presentation of the flight could have some fun uses. Passengers might benefit from a "clear" view of the outside environment when they are actually IMC. Not only it would be fun to watch, but also they would be assured that they are not about to hit mountains, etc. Lots of passengers don't mind flying in good weather, but are afraid of what they *don't* see in the clouds. This could well be an evolution of the moving map already displayed in the passengers' cabin. Also, the recent trend in real-time internet flight-following could benefit from the actual point of view of a particular flight being followed. I think this would produce a quite interesting sense of "being there". In both cases the use would be for amusement only and of course out of the control loop, so any inaccuracies would not endanger the flight. Pretty interesting stuff to think about. Thanks for the opportunity! :wink: Best regards, Bruno.

Peter, Indeed by saying "via FSUIPC" I meant using the FSUIPC drop-down list to assign keystrokes to up and down freq changes. I am doing this now with the keyboard itself, but will later use a keyboard encoder (Hagstrom KE72) to feed a rotary encoder's pulses into the PC and let FSUIPC translate (using its drop-down list) those keystrokes into FS commands. Thank you for showing me how to disable the stanby frequency in the .CFG file. It id the trick. As for the ADF... yes, it was the Boeing ND I was thinking of. It does show the ADF as you descrtibed, but I only got it to show the NDB 3-letter identification (if a valid, in-range frequency is selected) or the word "ADF" otherwise. As yet I did not manage to display an ADF frequency in the ND, but I will look deeper into PM's manual for that. Please accept my wishes of very best luck with your eyes' condition. And of course, many thanks for sharing your time with so many hobbists. Best regards, Bruno

Hi Pete, Sorry if this has been covered in other threads or in the documentation. I couldn't find anything related to this, so here it goes. I am trying to change the NAV frequency via FSUIPC and indeed I have done it, but I can only access (and change) the standby frequency (standard Microsoft B737, FS2002 or 2004). I thought I should be able to directly change the active NAV frequency (as the Lear model in FS2004 seems to do). The reason I would like to do this is to see the resulting change in Project Magenta's ND and therefore bypass the need for a dedicated LED display in a cockpit project of mine. Of courese, even if this could be done, I am still left with the problem of displaying the ADF frequency (which is not displayed in PM's ND). But I would already be happy enough changing NAV1 and NAV2 snd seing the result without building special hardware. Thanks for your thoughts, Bruno.

Pete, OK, will try going there. Thanks for the prompt reply (as usual!) Regards, Bruno.

Hello Pete, It was probably going to happen some day. I had an HD failure in my computer and did not think it was a big problem because I've backed-up just about everything. But of course I blew it with FSUIPC. The copies I found on CD are old, unregistrered versions. Is there a way of retrieving a key? What sort of information would I need to send you to identify myself as a registered user? Also, I am not sure of the exact version I had registered... is this an issue? Thanks, Bruno.

I said, "At this point I am not sure what the correct procedure is for retrieving the keys." But simMarket.com has just e-mailed me another link, this time with all the keys, so please disregard my previous message. Best regards, Bruno.

Hi Pete, This morning I ordered FSUIPC and WideFS from simMarket.com. I got a "thank you" e-mail from them, with a link to a history page with details of the transaction. However, that page did not contain furhter links or other information as to how I can obtain the keys for registering FSUIPC or WideFS. I am just starting to venture into FS add-ons and will probably need some assistance along the learning curve :) At this point I am not sure what the correct procedure is for retrieving the keys. I have an order # from simMarket.com, if that is necessary. Very best regards, Bruno.