Pete Dowson

Please describe exactly what you mean by "failed to do anything". What actually happened? Yes, of course, it should be. It is standard Wndows code, compiled using the same compiler as FSUIPC3 itself. It is better certainly in the sense that I will not support older versions. Let me know more about the problem and we'll fix it. Pete

Sorry, can you explain what it is you want to "disconnect" for? This is all to do with simulating failures. Is that what you want to do? If you merely want to control the rudder trim, just write to offset 0C04 (FSX only) or 2EC0. 2^0 is bit 0, value 1. 2^1 is bit 1, value 2 .... 2^7 is bit 7, value 128. My cockpit has a rudder trim dial which is used to write directly to 2EC0. You only want to disable the connection to stop a use changing the trim with his own device (eg joystick) or to simulate problems. Regards Pete

Sorry, but can you be more explicit please? Are you reading FSUIPC offsets, or trying to get this information some other way, like through SimConnect or in a gauge? If FSUIPC, which offsets are you looking at? And which version of FS? Regards Pete

Actually they weren't "remembered" but cut and pasted from the "List of FS2004 Controls" document. Here are the complete entries for "COM2": COM2_RADIO_FRACT_DEC 66438 COM2_RADIO_FRACT_DEC_CARRY 66439 COM2_RADIO_FRACT_INC 66440 COM2_RADIO_FRACT_INC_CARRY 66441 COM2_RADIO_SET 66442 COM2_RADIO_SWAP 66444 COM2_RADIO_WHOLE_DEC 66436 COM2_RADIO_WHOLE_INC 66437 COM2_STBY_RADIO_SET 66443 COM2_TRANSMIT_SELECT 66464 The numbers are the internal control codes used by FS. For the drop-down list FSUIPC merely replaces underscores by spaces and uses lower case. It is strange that in your picture, showing the drop down list section, some of the COM2 entries are missing. I don't understand that! (I also don't understand how you are seeing some of the numbers to the right in the drop down list. They should be too far to the right to see). Can you tell me the FSUIPC version number please? If some of the FS controls are missing in the drop-downs it means they are missing in the tables in FS's "CONTROLS.DLL", as that is where they are from. The "List of FS... Controls" documents I publish are actually derived directly and automatically from that FS module. [LATER] I've now checked. The FS2004 controls list is okay, but the FSX controls list does have some missing! Yet they were there when I made the list for FSX which I published! I can only think that they got lost in either the SP1 update for FSX, or possibly SP2 or Acceleration. How bad is that? And I wonder what else they lost? I shall have to do a comparison ... I can add these missing ones "artificially" -- I'm sure they must be still there, by number, and it is just the list which is corrupted in a later version of CONTROLS.DLL. I can test for them and add them from my own internal list if they aren't present. Look out for an FSUIPC4 update in due course, maybe before the end of the week. Regards Pete

As stated in the FSUIPC user guide, if you want to use a reverse zone on a single throttle, assigned for "all engines" in FS or FSUIPC, you must map the throttle to the 4 separate throttles using the checkbox shown for it. If you can see it operating as a single throttle, you evidently haven't read the documentation and you are instead calibrating it as a single throttle. Press its Reset button to undo that. The reverse zone is not available on FS's single all-engine throttle control. Pete

They most certainly have not approached me for a commercial license and therefore that action is not approved. If I get proper confirmation that they are using FSUIPC commercially I will have to take some action. I am certainly not going to support their use unless it is agreed and paid for! Regards Pete

The installer runs fine but it gets an error? That makes no sense. It cannot run without the Microsoft run-time library being installed, but neither can FS either! Your log shows the Installer running okay. What you are saying makes no sense to me at all. Sorry. Pete

Not that I know of. What would such a simulation actually do? Unless you are actually connected to an ATC which needs to receive the transponder, the operation in the different modes is pretty much invisible -- bar perhaps the flashing "reception" indicator. I simulate that on the PFC transponder, including the longer flash when ID is pressed, indicating the longer ID response. If you fly on-line using FSInn or Squwakbox then they implement their own means of getting the transponder mode indicated to them. Squawkbox 3 on FS9 uses FSUIPC for this, but Squawkbox 4 and FSInn do not. Regards Pete

Do you mean the drop down list in FSUIPC assignments? If so there are all these: COM2_RADIO_FRACT_DEC COM2_RADIO_FRACT_DEC_CARRY COM2_RADIO_FRACT_INC COM2_RADIO_FRACT_INC_CARRY COM2_RADIO_SWAP COM2_RADIO_WHOLE_DEC COM2_RADIO_WHOLE_INC Of these only the "SWAP" one affects the in-use frequency (unless your aircraft configuration states that COM2 doesn't have a standby setting). In fact the only way to address the in-use frequency directly is to use the specially added FSUIPC-extra controls: Com2 use whole inc Com2 use whole dec Com2 use frac inc Com2 use frac dec Please use the documents provided. The LIST of FS controls I publish can be searched quite easily. Search on "COM2". Regards Pete

FS doesn't simulate transponder modes in any case -- this is why there are no controls. Regards Pete

I don't think it did. I just get worried that there's something in the way I've written the stuff up which is misleading. Naturally this part is intended for programmers, but maybe too much is assumed. Hope everything works for you now! Regards Pete

FSX needs that DLL too, so can you run FSX? If you cannot run the Installer, how is it you managed to get an Installer log? How did you install FSUIPC? Seems the installer runs fine! So, what are you trying to do now? Just run it again if you want to register or re-register. Regards Pete

You could just try the examples provided. With the Lua files in the FS Modules folder, you can assign them to button or keypresses, as "Lua " Okay. File creation in Lua is easy too -- take a look at the example. Here, I'll print it out for you (it's the "record to csv.lua" file): -- "Record to CSV" example data logging LUA plug-in, by Pete Dowson, September 2008 -- Open an exisitng "FSrecord.csv" file to append to, or create it if it doesn't exist -- It will go into the Modules folder because I've not included a full path (like "C:\....") -- By using "assert" you get an error message if this fails f = assert(io.open("FSrecord.csv","a+")) -- write the CSV column headings f:write("\r\nmsecs,timeL,timeZ,lat,lon,alt(ft),pitch,bank,hdgT,hdgM,vs,ias,tas,gs,mach\n") -- note the elapsed mSecs count now so can provide relative mSec timing column time0 = ipc.elapsedtime() -- Loop until our Flag 0 is set (by assigned FSUIPC control) while not ipc.testflag(0) do -- Set the timestamp for this loop time = ipc.elapsedtime() - time0 -- Read all the data we want from FSUIPC hour, min, sec, hourZ, minZ = ipc.readStruct(0x238, "5UB") gs, tas, ias = ipc.readStruct(0x02B4, "3UD") lat, lon, alt, pitch, bank, hdgT = ipc.readStruct(0x0560,"3DD", "2SD", "1UD") mach = ipc.readUW(0x11C6) vs = ipc.readSW(0x842) -- now convert them all from FS units into those we normally recognise gs = (gs * 3600) / (65536 * 1852) tas = tas / 128 ias = ias / 128 mach = mach / 20480 vs = vs * -3.28084 lat = lat * 90 / (10001750 * 65536 * 65536) lon = lon * 360 / (65536 * 65536 * 65536 * 65536) alt = alt * 3.28084 / (65536 * 65536) pitch = pitch * 360 / (65536 * 65536) bank = bank * 360 / (65536 * 65536) hdgM = hdgT - (ipc.readSW(0x02A0) * 65536) hdgM = hdgM * 360 / (65536 * 65536) hdgT = hdgT * 360 / (65536 * 65536) -- but only log this time IF we aren't in an FS menu, or loading scenery -- (check the "ready-to-fly" flag word at 3364) -- and provided we are not paused (flagged at 0264) if (ipc.readUW(0x3364) == 0) and (ipc.readUW(0x0264) == 0) then -- write a CSV line to the open file f:write(string.format("%d,%02d:%02d:%02d,%02d%02dZ,%02.4f,%03.4f,%.1f,%.2f,%.2f,%03.1f,%93.1f,%d,%d,%d,%d,%.3f\n", time,hour, min, sec, hourZ, minZ,lat,lon,alt,pitch,bank,hdgT,hdgM,vs,ias,tas,gs,mach)) end -- 20 times per second, roughly (allow 2 mSecs overhead) ipc.sleep(48) end -- tidy up at end ... f:write("\n") f:close() -- end of example program Note that this runs forever or until you set its Flog 0 (using a key or button assigned to the "LuaSet record to csv" assignment with parameter 0 (from the Flag number). Ah, not so much I (I don't know .Net managed languages I'm afraid) as other kind users donating their work. Yes, well, I don't understand that stuff. Sorry. Not sure "erratic" is the correct word. All I'm saying is that you certainly should be able to read stuff at fairly close intervals, but that those intervals won't be all the same because of the many unpredictable timing changes which are inevitable. If you have a multicore PC running fast enough for FS to run with ease, then you might expect a more regular service, but seeing as there a process switches and message queues to contend with on every transaction, then apart from whatever might be loading FS down, you aren't going to get precise intervals. It would be easier to achieve in Lua because there are no process switches or message queues involved, but even that is subject to FS's performance needs as they vary. In the end you have to accept what you get, then if you need precise intervals, compute those intermediately timed values by interpolation. Have to tried using FSInterogate in a reading loop with the same set of values, to see how regular that appears? You can reduce its polling interval, I think, to quite a low number of mSecs. FSInterrogate will be more efficient, code-wise, as it it Native code, written and compiled in Delphi. (I never did like managed code. Too inefficient an idea for my tastes ;-) ). Regards Pete

I can't help with the VB, but you should be aware that version 4.50 is old and unsupported. 4.53 is currently the oldest supported version for FSX, and 4.56 will be released before Christmas (I hope). From the log it appears you are connecting okay but never actually reading anything from FSUIPC -- the two accesses logged are standard ones from the Open call. I don't see any reads in your code either, but then they could be hidden for all know of this programming system! ;-) Regards Pete

Yes, you can do that. In fact there is a Lua plug-in supplied with FSUIPC which does just that, and with a lot more information too. It is one of the examples in the Lua Plugins package -- it actually creates a CSV file, loadable into Excel, for example, but it could easily be adapted any way you like. Okay. It is also easily possible with that. Even over a Network you should be able to attain 100 mSecs, often quicker, but more variable. If you want it really regular the Lua plug-in method can't be beaten as it is running inside FS's process and saves the unpredictable affects of process changes and message queues. Variable intervals are inevitable with separate processes -- it's the way Windows timesharing and message passing works. If you needed definite regular intervals you'd probably need to interpolate. Sorry, I don't understand this part. "disconnecting"? You aren't reading them all with separate Process calls to FSUIPC are you? You should build the total request per cycle, using FSUIPC_Read (which takes no time at all as it is only an internal data build function), the do the one FSUIPC_Process call per loop. Of course, only Open and Close the connection at the beginning and end of the program, respectively. Regards Pete

Sounds like you aren't following the request protocol. Both the signature and the ICAO id (or Lat Lon) must be written in the same FSUIPC write call, or else in two writes but in the same Process call with the ICAO then written first. The activating offset is the signature. If you get this wrong you'd get exactly the effect you describe, because it will be using the previous ID or location. Because Simconnect behaves differently, and that's where I've come from. No, SimConnect does NOT behave differently. FSUIPC is using SimConnect 100% for weather. What you get is EXACTLY what SimConnect returns if you ask for weather AT a latitude/longitude. Evidently you've never done this before, and I'm not sure why you want to now, via FSUIPC, when you never did directly? It only does so for Lat/Lon or "at aircraft" weather. I don't understand how you expected weather at any chosen location to be anything other than interpolated. FS does not store weather for every possible position, it interpolates between weather stations. You can't change weather at any lat/lon, only at weather stations. This is an FS restriction -- it doesn't store weather at every location. To select a weather station or a lat lon you simply put the mouse in the correct place and press Enter, as documented. If you select a weather station all of the other fields will accept Enter and come up with an editing dialogue for the values. Oh dear. Sorry, but how do you get yourself so confused? If you write to CC00 you read from CC00, not C000. Please see the descriptions for each slot, from the text documentation: C000-C3FF (Area 0): Weather at aircraft C400-C7FF (Area 1): Last set global weather C800-CBFF (Area 2): Weather setting area CC00-CFFF (Area 3): Weather reading area If you are reading weather by request you use CC00. Nothing you do in CC00 will affect the C000 area which continues on doing its job regardless, as does C400. Sorry if I appear impatient, but I don't understand what it is that gets you so confused. Sorry. Even relatively non-programmers have not been confused by this clear demarcation of offset functions. What is it that makes it so for you, now? I'll fix it if I know. Pete

With FSUIPC4 you NEVER register within FS -- there is no provision for it. You register in the Installer, before running FSX. There is no message in FSUIPC4 talking about running in Administrator mode! There is no need and never has been. since FSUIPC 3.93 you register it too via the Installer, though there is still an option to do it in FS -- but for the latter you do certainly need to use Admin mode. Best to always register via the Installer. It has the privileges automatically. Nonsense. I am using both FSUIPC3 and FSUIPC4 with Windows 7 RTM, and before that Windows 7 RC since it was first available. There's absolutely no problems at all with it. Regards Pete

Yes, it is fully working in all versions of Windows. But do try the latest incremental release available in the Updates announcement above. If you still get a problem, it might be related to a corrupted weather file in your Flight Simulator Files folder, or to an add-on using FSUIPC. Regards Pete

Is FSUIPC involved in this somehow? I know RealityXP don't use FSUIPC. Didn't you think of looking in the FSUIPC Options on screen, or perhaps in the supplied User Guide? It's a checkbox on the Miscellaneous tab marked "Make NAV freq increment = 50KHz", and explained in the relevant section in the documentation. I didn't think it was that obscurely labelled. ;-) Regards Pete

That's because the client is not receiving anything from the Server and times out. The Server sees the client connecting and sends it stuff, which evidently never arrives, and eventually dumps the connections -- but there's an overlap time where the Client's new attempt to connect comes through. Well, hardware failures excluded, something certainly must have changed! Yes, this shows exactly what I said. The timeouts are regular, at the interval indicating nothing being received - 30 secs initially, 20 thereafter. And all that in the Server log shows why the Client never receives anything. The Server is being blocked. Something is most certainly wrong on your FS PC side. Firewall or Anti-virus activity most likely. Regards Pete

It returns the ???? for requests for weather at a location, because such requests have nothing to do with weather stations. They report interpolated weather. It's a different SimConnect API call. If you enable SimConnect's logging you'll see. Okay, understood. Sorry, i did not read your code in the first place. It is really not for me to comment on code I don't understand. Sorry. Okay, good. The 4 spaces call uses a different API into SimConnect as you'd see if you logged it. The call is SimConnect_WeatherRequestInterpolatedObservation It is the only call which gives weather at specific locations rather than at weather stations. If that is not what you want, best not to use it. Sorry, I'm not sure why you would not know this if you have already implemented a direct SimConnect interface. Out of sync with what? But that's what you always get. That's what that call is for -- not to get weather at a weather station, but to get weather at a Lat/Lon location. How do you expect to have an ICAO ID for every lat/lon location? The ???? signifies it isn't a Weather Station METAR. Evidently you've not read the short text documentation at all? It isn't very long and shouldn't be too much of a chore to read. You can use WeatherSet2 to set weather at stations and to read weather at weather stations or at Lat/Lon locations. How to do it is set out in easy-to-read short text. WeatherSet2 was written as a test aid for the NWI, just as WeatherSet(1) before it was the test aid for the AWI interface. But the request was made in the area where the timestamp is relevant, of course. Isn't that logical? Why have a timestamp in a place divorced from the request? Please apply a little logic and the answers to your questions will be easy. The METAR strings being returned are just a bonus for FSX, additional to the original NWI facilities transposed from FSUIPC3. Why would I then move the timestamps away from their place associated with the request and the returned interpreted data? Can't you see that would be nonsense? Regards Pete

So, you don't have a problem reading weather at "nearest weather station"? No. Global weather is "GLOB". Where are you reading this "????"? That's normally part of the FSX Metar string for weather at points which aren't weather stations. It is also used in requests to get weather at the user aircraft. Surely the FSX Offsets Status tells you, or at least implies, that the facilities are totally compatible / identical, except for the extras mentioned, like the METAR strings facilities. The differences in the areas you mention are explicitly colour coded -- blue for additions, red for differences. You seem to miss some of the point of FSUIPC, and that is compatibility. I dared not change the NWI. I even had to support the old AWI and the older still FS98 weather offsets. All of them, all supported in FSX, all in the name of compatibility! Urrrggghhh. Two important points there. first the ID code to force FSUIPC to use the Lat/Lon is [b]FOUR SPACES[/b][i] not[/i] ""!! Check again item 2 in the list of steps for reading the weather: Second, there is absolutely no point using any old "waypoint identifier, which may be an airport ICAO, VOR id etc.". If you are providing an ID it must be a weather station known to FSX -- most 4-letter airports are (but not all). Rarely US 3-letter airports, and certainly no waypoints, VORS etc. You just won't get a meaningful response for unknown weather stations. If you don't know, always use Lat/Lons. Programs like Radar contact use only lat/lons, not IDs for just that reason. Use weather logging. Use WEATHERSET2 to compare results. Double-check that you are reading and writing the right things in the right sequence. It is always applicable. It tells you when data is available. Getting the weather is NOT immediate -- a request is placed. The data arrives later. The reading interval could be anything for 1 to several seconds -- SimConnect is a busy beast and FSUIPC refuses to overload it with weather requests (though this is adjustable with obscure parameters). The relevant timestamp is ALWAYS the one in the zone in which you are performing the transaction. How else could it be? What would be the point otherwise? Regards Pete

To use an axis as a spoiler you need to select the "REV" option, in the calibration section, BEFORE attempting to calibrate. Naturally, with full forward being "off" it must be reversed. Don't try to reverse it after calibrating otherwise the values will be all wrong. And don't try testing it on the ground. FS has a habit of deploying it when you pass through the "ARM" range when you are on the ground. The same usually applies to toe brakes as most hardware implementations of toe brakes have them sendng the maximum value whem the feet are off. With FSX the Hat is best assigned as an Axis to "pan view". If you'd rather use it as a set of 8 buttons you assign it in the Buttons section instead. Regards Pete

The fact that an axis assigned to a throttle cut the engine when pulled back is really a pretty sure indication that it is also operating the mixture, so I really do think you missed something. Generally, also, if you ever unplug a USB device and reconnect it, FSX will automatically re-enable it and reassign axes. Don't forget also that in the FS assignments each connected device has its own assignments separately displayed, and you have to select each in turn in the main dropdown in order to see them. If you have two identically named devices it can be easy to overlook assignments. Rather than delete individual assignments, if you are assigning everything in FSUIPC, it is best to actually disable the controllers altogether. But again you have to do that for each one specifically -- and they still may come back when reconnected. You can find out what is going on more scientifically by enabling logging. In the logging tab, put a check mark against the Axis logging. It will likely create a large log indeed, so don't leave it on all the time. If you run FSX in Windowed mode (just whilst you are sorting this out), you can also opt for the console log display and see exactly what is happening in real-time, on screen. Regards Pete

4.53 I hope. 4.50 is old and unsupported. Sorry, I don't understand any of that. you can assign any quadrant lever to any FS control or FSUIPC control. In that case you also have that "throttle" assigned to the mixture -- probably a default FS assignment. You should not assign both in FS and in FSUIPC. Choose one or the other. That absolutely doesn't matter at all. Just assign it to what you want. The NAME of the axis is NOT the same as the use it is put to -- you can use any axis for anything. You are just confusing yourself. You have it assigned to throttle 4 then, not throttle 1. If the one lever operates throttle 1 and throttle 4 it sounds likely you have duplicate assignments, again. As I said, you should not have assignments in FS and in FSUIPC for the same axis. Again, you are probably confusing yourself with dual assignments! Well, if you do that you most certainly will NOT get any reverse zone!!! It is explained in the documentation. If you don't understand it, best to leave it alone. It is to avoid problems with certain add-on aircraft (mainly the fly-by-wire types which use those controls when doing so). I think you don't understand about FS assignments or FSUIPC assignments. Choose one or the other, never both. Maybe it would be best to simply delete your FSUIPC4 INI file, assign everything in FSX, not in FSUIPC4. You can still calibrate in FSUIPC4, just don't use the assignments facility which is obviously too confusing for you. There's no need in any case if things work okay through FSX. And please do NOT use olde unsupported versions of FSUIPC. Regards Pete