Pete Dowson

Yes. As far as i know that's how most Saitek users do it. Looking at the log both Thrttle1 and Throttle2 seem to be rapidly alternating between two values: 279610 *** AXIS: Cntrl= 65820 (0x0001011c), Param= 0 (0x00000000) THROTTLE1_SET 279610 *** AXIS: Cntrl= 65820 (0x0001011c), Param= 701 (0x000002bd) THROTTLE1_SET 279563 *** AXIS: Cntrl= 65821 (0x0001011d), Param= 0 (0x00000000) THROTTLE2_SET 279563 *** AXIS: Cntrl= 65821 (0x0001011d), Param= 701 (0x000002bd) THROTTLE2_SET Are you assigning in FSUIPC to those controls, or to Axis Throttle1 Set and Axis Throttle2 Set? If not the latter change over. But first, before loading P3D, in the [JoyStickCalibration...] section for your A320 in the INI file, change this: UseAxisControlsForNRZ=No to UseAxisControlsForNRZ=Yes then re-calibrate in FSUIPC with a dead zone at idle (minimum). However, if the A320 really doesn't like doing a reverse setting even with FSUIPC not doing anything, then I don't think anything in FSUIPC will help. Pete

Please see the Miscellaneous tab in FSUIPC Options, and page 14 in the User Guide. Pete

That sounds like your throttle lever is jittering, sending different values to the Sim all the time. If you calibrated in the Sim, try setting a null zone. Same if you use FSUIPC. And don't assign axes in both FSUIPC and P3D. If you use FSUIPC for assignments ensure controllers are actually disabled in P3D. Otherwise you will get conflicts. I think also that the Aerosoft A320 is a bit like the PMDG Boeings and has its own way of doing things with axis inputs. If you assign in FSUIPC don't assign "direct to calibration", but to the FS controls "Axis throttle ...". It might not like you calibrating in FSUIPC either. Well, that's patent nonsense. But we are used to it -- FSUIPC always gets the blame, it's their easy way of not bothering to help properly. Pete

There is no compatibility. It will need a completely new FSUIPC, and not all facilities may be possible. There's really not enough information available yet, even to developers, for us to say anything definite. Don't forget it is still in its "Alpha" stage, one which is normally not seen at all outside the developing company. There's a long way to go. Pete

Just install again. It won't overwrite a newer version, but will replace an older version with the new one. The documentation may also be updated. Your settings, macro files and any Lua plugins aren't touched. Pete

Ouch. If you've been doing that all the time then you create a new Macro file for every assignment! You should name the Macro file for the profile or collection of functions you are assigning. THEN create all the macros, only going back and ending mouse macro mode when you've done. Each named file can contain many named macros! When I said no limit I had assumed you were following that documented method. You've probably created over the limit for FILES. Each macro file can have many macros. I don't recall the precise limits at present, but no one can really get anywhere near the limits with normal use. Please review the explanation in the User Guide, page 31 and following. On page 32, starting with "Okay, on with the example ..." you'll see that we name the file THEN proceed to createall the macros for that file ("King" in this case). A bit later (last paragraph on page 32) please note that it says "Keep doing this for all the functions you want", and only after that you see this paragraph: When you’ve finished adding macros, go back to the FSUIPC Keys or Buttons options, and click that End Macro Making button. The file will be written, and then loaded into FSUIPC’s keys and buttons drop-downs ready for use. I'm really not sure how to advise you going about rectifying what you've done. Macro files are text files so you can edit them and put all the macros for each profile into one file, with each line numbered in sequence, but then your assignments to keys or buttons will all need re-doing. As an example, looking at your INI file, I see all these files just for the B777: [MacroFiles] 1=B777 land1 2=B777 land2 3=B777 land3 4=B777 taxi1 5=B777 taxi2 6=B777 taxi3 7=B777 storb 8=B777 nav 9=B777 logo 10=B777 beacon 11=B777 wing 12=B777 apu 13=B777 eng1 14=B777 eng2 15=B777 ext pow 16=B777 batt 17=B777 apu2 18=B777 emr light 19=B777 aider 20=B777 tcas on 21=B777 tcas off 22=B777 start1 23=B777 start2 24=B777 seat 25=B777 seat off All those should be in a single file called "B777", containing macros named "land1", "land2", .... "seat off". You'll notice in your [Buttons.B777] section annotations made like -{Macro B777 land1: land1}- Meaning file B777 land1, and the macro called land1 within. That is actually encoded in this part:: CM1:1,0 C means "Control" M means "Macro" the first 1 refers to [MacroFile] number 1 (see list above, it refers to "B777 land1") then the :1, 0 means the macro on line 1 in that file (denoted by starting with 1=), with parameter 0. Armed with this information (which I think may also be in the Advanced User's guide), you could conceivable put all the macros into proper files with sequenced line numbers, AND edit the assignment lines to match. But you might find it easier to start again. If you wish to do that you'd need to delete all of the files of type .mcro and also delete your FSUIPC5.INI (or just delete all the [Buttons...] sections. Do this before loading P3D. Pete

No there are no limits. You need to explain exactly what you are doing. Do you have a separate profile for each of those aircraft, or are you assigning to different keys or button (and are you using keys or buttins?). Are you talking about mouse macros or some other macros you've obtained from somewhere? And which exact version (by number please) of FSUIPC5? Pete

You are welcome. Good flying! Pete

Make sure both PCs are in the same workgroup, otherwise you'll need to set IPAddr or ServerName and Protocol parameters in the WideClient's INI file (as stated in the documentation). Win10 and Win7 have different default workGroup names. Pete

For an ILS, the Glideslope location is 085C and the Localiser (which you are calling the VOR) is 0874. True VORs don't have LOC or GS. Pete

Today I finally managed to start tedting this for you -- but on P3D4 using FSUIPC5, as I said. I used the same details as yourself, excepting as there's no Cessna I used the Baron 58. On the threshold of Runway 25 at EDDK with 111.10 and 109.10 on NAV1. Offsets 0C4D, 085C and 0874 each reported correctly, and were correct on every swap of the frequencies. I repeated this many times till came to the conclusion that it just wasn't going to go wrong. The data from SimConnect always arrived in exactly the same order, every time, the sequence for 109.10 being: 2614717 SimRead: 0C4D="NAV HAS NAV:1" [also 0C4A] INT32: -1 (0xFFFFFFFF) 2614717 Monitor IPC:0C4D (U8) = 0x0 2614717 SimRead: 0C4D="NAV BACK COURSE FLAGS:1" [also 0C4A] INT32: 131 (0x00000083) 2614717 Monitor IPC:0C4D (U8) = 0x40 2614717 SimRead: 0C4D="NAV HAS GLIDE SLOPE:1" INT32: -1 (0xFFFFFFFF) 2614717 Monitor IPC:0C4D (U8) = 0xC0 2614717 SimRead: 0C4D="NAV HAS LOCALIZER:1" [also 0C4A] INT32: 1 (0x00000001) 2614717 Monitor IPC:085C (U32) = 5652883 2614717 SimRead: 085C="NAV GS LATLONALT:1" [also 0864] [also 086C] FLT64 Lat=50.86704724, Lon=7.152247131, Alt=92.04901123 2614717 Monitor IPC:0874 (U32) = 5652010 2614717 SimRead: 0874="NAV VOR LATLONALT:1" [also 0878] [also 087C] FLT64 Lat=50.85919004, Lon=7.120706588, Alt=92.04901123 and then for 109.10: 2616714 SimRead: 0C4D="NAV HAS NAV:1" [also 0C4A] INT32: 0 (0x00000000) 2616714 Monitor IPC:0C4D (U8) = 0xE8 2616714 SimRead: 0C4D="NAV BACK COURSE FLAGS:1" [also 0C4A] INT32: 0 (0x00000000) 2616714 Monitor IPC:0C4D (U8) = 0xA8 2616714 SimRead: 0C4D="NAV HAS GLIDE SLOPE:1" INT32: 0 (0x00000000) 2616714 Monitor IPC:0C4D (U8) = 0x28 2616714 SimRead: 0C4D="NAV HAS LOCALIZER:1" [also 0C4A] INT32: 0 (0x00000000) 2616714 Monitor IPC:085C (U32) = 0 2616714 SimRead: 085C="NAV GS LATLONALT:1" [also 0864] [also 086C] FLT64 Lat=0, Lon=0, Alt=0 2616714 Monitor IPC:0874 (U32) = 0 2616714 SimRead: 0874="NAV VOR LATLONALT:1" [also 0878] [also 087C] FLT64 Lat=0, Lon=0, Alt=0 So, since the coding in FSUIPC5 in this area is identical to that in FSUIPC4, I can only conclude that it is a bug, or data timing error, in the SimConnect in FSX SP2. Have you never thought of updating at least to FSX-SE which had a number of corrections to bugs in FSX, and which was also recompiled with more modern versions of the compiler, leading to more efficient code. Alternatively, if you don't want to move to proper 64-bit, P3D3 would be a good choice. (Though I do not currently have dbugging facilities for either, I'm afraid). Pete

There's no file made by us called FSUIPC.exe! There's Install_FSUIPC.exe, which you must surely have already run once in order to install FSUIPC. Just run it again to enter WideFS registration -- on the FS2004 PC (or FS2002, or FS2000, or FS98? You don't say which), not the Client PC. Make sure you have the latest version of FSUIPC3 -- 3.999z9b, as in the title of tyhe thread you posted in. See Download Links subforum above, Updated Modules thread. Pete

As Thomas said, the valid settings only include Yes, No and Substring. The default is Substring, which means profile assignments can work with any part of thename listed in its [Profile...] section. To set profiles for different aircraft, apart from just assigning them in the options when you load them, to add their names to the list in the relevant [Profile ...] section of the INI. It is there, because of the "ShortAircraftNameOk=Substring" setting (defaulted in your case), where you can list names like PMDG for all PMDG aircraft, or 737 for all 737's, and so on. Use as much of the name (aircraft title) as you need to avoid getting unwanted aircraft with the same part in their title. So for just the PMDG 737NG you could use 737NGX. Pete

Sorry, I've been 100% tied up trying to get my setup back up in time for a visit I've got tomorrow (travelling from Australia) to do some updated visuals for my cockpit. I haven't forgotten, and should get around to testing this during this week. Meanwhile, because even if there is a problem in FSUIPC with timings regarding SimConnect callbacks (because that is what I am suspecting), I can get it fixed in FSUIPC5 which is still in development, but probably not FSUIPC4 which stopped development over two years ago. This is why I thought you might use the deviation indications instead. Pete

So you don't use the glideslope deviation value in offset 0C49? Prefer to do it the hard way? You've also got 0C48 for the localiser deviation. Looking at the video you linked to, I'm not sure how this relates. There are changing moving Lat/Lons for a ship -- I didn't even know they had VORs/ILSs! Pete

Yes, 0C4D bit 7. I'm afraid I've got problems to sort out here befre I can investigate this (I think I need to reinstall windows), so it will be later in the week. In any case if it is a bug in FSUIPC I can get it fixed in an FSUIPC5 release, but I'm not sure about FSUIPC4 which was frozen a couple of years back (after 14 years of continuous development). Seems odd no one came u with the problem you report in all that time? I'll let you know what I can do. What do you use the Lat/Lon/Alt value for when on Approach, exactly? And just for clarification , are we talking about the VOR signal for the localiser, when you want the ILS glideslope transmitter location? Pete

Maybe the ILS reception has faded too much to be recognised -- did you check the flag which determines this? Pete

Hmm, that is very strange. Are those bits of log immediately after you did a "swap"? I'll need to find time to check this on FSUIPC5 ... maybe over the weekend. Please remind me if I haven't got back by monday. I seem to have a lot on and, being old, tend to forget and mislay things (I've written a Note to myself and left it on my desk! 😉 Pete

Actually, reading the documentation more carefully, it appears that 085C is supposed to be the VOR latitude, always. Offset 0874 is the same except when NAV1 is tuned to an ILS in which case it is the ILS latitude. So, if there is an error, isn't it that 085C isn't maintaining the VOR latitude when NAV1 is on an ILS? I'll look at the code, but I'm wondering if the problem is actually more to do with when the NAV1=ILS indication is provided by SimConnect. If there was a delay it would explain the change you are seeing, albeit very quickly. Whether it is an ILS is indicated by bit 7 in offset 0C4D. The SimConnect variable for that flag is "NAV HAS LOCALIZER". So, could you repeat the test but not only monitor 085C, as you have, but also 0874 (also a U32), and 0C4D (as U8). Then you could see if you get the results you want with offset 0874 . Pete

Aha! Okay, so the SimConnect value is correct, but something is going wrong in FSUIPC after it is received. I'll check it out in FSUIPC5 as I am now set up to debug that rather than FSUIPC4. It might not be for a couple of days as I've got a lot of prior stuff to get through. Pete

The log tells me nothing I'm afraid. In the Monitor facility please make sure you check the "normal log" option so the entries appear in the log. We need to show that it is SimConnect providing the wrong value. Monitor the offset you are concerned with (085C) as type U32, then show me the log pointing out where you think the Sim is getting it wrong. And please DO NOT use the "New Log" button to make FSUIPC start a new log. I also want to be able to see the initialisation entries! AND close the session and show the complete log please. Unfortunately, even if we gather solid proof that FSX is in error, it won't get fixed. But maybe Iit can be tested in P3D4 so that L-M can be asked to fix it. Oh, i'd also need to know that both the aircraft and scenery in use is default, and no NAVAID updates from Herve Sors or FSAeroData. Otherwise L-M won't want to know. Pete

First off you need to update to the currently supported version 4.974. The one you are using is very old. Check on fsuipc.com Only after you'd done that, add the monitoring as I requested and show me the log file after a session in which you see the problem. Please note down what I should look for. Pete

You'll need to state which Flight Simulator you are talking about, and which version of FSUIPC. If you use the Monitor facility in FSUIPC Logging tab, right-hand side, then, assuming you are using FSX or later, not FS9 or before, then FSUIPC will log exactly the value it receives from SimConnect, along with the Sim Var name. If this is wrong it points to either a bug in that version of F, or possibly a bug in the nav data in the scenery. FSUIPC doesn't manipulate the data received except to put it into the same units as FS98, FS2000, FS2002 and FS2004 used to provide. It does this to provide ongoing compatibility. Pete

Yes. Re-run the Installer, as stated in the documentation supplied. Pete

Good. Well done. Make sure also that you are using Joy Letters. You can either choose the letters yourself or let them Auto Assign via a parameter in [JoyNames]. That should help guard against other cases of GUID changes. (There's a chapter in the User Guide explaining Joy Letters). Pete