Pete Dowson

Sounds exactly like conflicting assignments. Either the same switch/buttons are assigned in FS (perhaps automatically if you have not disabled controllers in FS), or you have multiple assignments in FSUIPC. You can use Button logging to see what action the buttons are inducing in FSUIPC, and event logging to see the events they cause -- see the Logging tab in FSUIPC options. The log is written to the Modules folder. Pete

I think that's true in North America -- and I don't think they have any 0.5 increments there either, so ADF's made purely for US and Canada use often have only 3 digit adjustment and display, even if digital. Europe have a lot of 0.5 frequencies. Frequencies up to 1200 or more are found in South America for sure, maybe other places. The FS ADF can tune pretty much the whole used range. How? Do you mean in the range settings on the right? You can only do 10 settings like that. If you are assigning to "offset word write", for offset 034C, yes you certainly need 0x0390 for 390.0. If you don't want the 1000 digit or decimal digit you should make sure offset 0356 is zero too. If you are assigning to the FS control "ADF complete set" then I think it needs to be in Hz, not kHz, but i'm not sure. Look it up in the FSX SDK. Either way I think you'd need to program it, maybe via a Lua plug-in, not rely on any direct assignment. But experiment for yourself. I've advised you all I can really. You need to do your own tests so you can see what is going on. Regards Pete

I don't have or use PMDG aircraft, but I'm sure all of those will be covered by PMDG's own control numbers. You do need your NGX fully updated, then you refer to a document in the NGX SDK which I don't recall the name of, but ends with filetype ".h" (which is a C/C++ header file). After the list of all the data it provides there's a list, by name, of all the controls. These are given as <some long name> + <a number>. To derive the actual control number find the number, at the start of that list, of the first part and add to it the number it shows to add. Then just assign your buttons/switches in FSUIPC by selecting <custom control> and entering the number. Some of those controls will need a parameter. On/off switches may need 1 for on, 0 for off, for instance. But I don't really know any more than that. Best for more help to go to the PMDG support forum -- or maybe first check in the assorted NGX threads in the User Contributions subforum here. Regards Pete

Sorry, but FSUIPC doesn't "process radio events". If you send events to FS they go to FS. The only time FSUIPC sees them is for logging purposes. FSUIPC is not involved at all apart from the logging, if enabled, and there is certainly no way it can re-order any events as it has no memory for them. Pete

I don't think you can make the potentiometer read any specific value very easily. They are simply not that accurate or predctable. Probably the easiest would be to program it for increments in one direction and decrements the other. If you want to try to map the range of values you get from the pot (which at best will be -16k to +16k, safter Windows calibration) to valid ADF frequcies in its complete range I think you might need to do it by program -- maybe a Lua plug-in. Bearing in mind that the full ADF range is 200.0 to around 1750.0 in steps of 0.5, you'd need a potentiometer with at least 3100 discrete settable positions. I've never seen one better than 1024 steps, and they are expensive and the 1024 is what they tell you, but I think it's optimistic. With most good quality ones you'd be lucky to get more than 120 predictable steps. You might do better going for optical, but even then over 3000 steps is a big ask. All you can do in axis assignments in the INI is scale values by a number and add an increment. I don't see how you'd ever be sure you could tune whatever value you wanted. Regards Pete

Seems that sometimes the device isn't ready to supply data, so it returns none -- making n = 0 so the program exits. The solution is to place the whole thing in a never-ending loop with a small delay to poll the device regularly. In other woords: Before this: -- read any data available from the device (only need most recent report) data, n = com.readlast(dev, rd) insert while true do and before this line: com.close(dev) insert ipc.sleep(200) end with a sleep of 200 mSecs you'll be checking it 5 times per second. Adjhust as needed. You are very confused still -- you really must differentiate between "offsets", which are tokens (actually places in FSUIPC memory) for data held by and manipulated in FSUIPC, and "controls" (FS calls then "events") which are numbers assigned to buttons and switches and sent to FS to make it do things. Offsets represent data, controls repearesent actions. Offsets range from 0000 to FFFF (hexadecimal), so have a maximum decimal number of 65535 -- but are always referred to in hexadecimal. They are listed in the Offserts List in your FSUIPC Documents folder. Controls can be almost any number, and also have names -- all of the FSX controls are listed in the List of FSX Controls document in your FSUIPC Documents folder, but there are also lots of ones added by FSUIPC and other add-ons like the PMDG 737NGX. In Lua, offsets are read by ipc.readXXX functions and written by ipc.writeXXX functions, where XXX defines the type of value -- byte, word, string, etc etc. In Lua, controls are sent to fS using the ipc.control function. I'm sure I've tried to make this clear before! I'm afraid I don't know which control your aircraft uses. Maybe either. Why not simply log controls in FSUIPC and operate it on the panel, then see which control it used? Pete

Sorry, but really I don't think this can be anything to do with FSUIPC. In any case, since 4.91, unless you actually enable one of FSUIPC's mouse functions it doesn't even touch the mouse -- except on behalf, perhaps, of Lua plug-ins using the Luamouse library. Maybe you have some such running? There are no such plug-ins supplied with FSUIPC. The only change between 4.90 and 4.92 in the mouse actions was to avoid re-showing the mouse pointer when it saw it moving. Since 4.91 it only does this if it was previously hidden, not by FSX, but by the added control in FSUIPC to do so. In other words, since 4.91 FSUIPC does LESS with the mouse, not more! (Unless you are using the hide mouse control for some reason). Regards Pete

Why do you want to use mouse macros for the NGX when they support assignable control numbers for pretty much every single switch? Mouse macros will only work with gauges written strictly to the FS C/C++ gauge SDK. Very few cockpits for FSX are written this way in any case. If you don't get the window appearing it just means it can't be done with that switch or gauge. That's way out of date and I cannot support it in any case. The current version is 4.921 or later. Please update if you want further support. Pete

You'd need to connect it through some sort of interface card. Normal computers can't just have potentiometers pushed into their orifices. Take a look at something like the Leo Bodnar boards. The right one will allow you to connect several potentiometers and send them to Windows via USB as normal joystick axes. Regards Pete

Yes. You have the 777 already assigned to the 737NGX profile. Maybe you used some short name for that asircraft, like just "PMDG"? Check the [Profile.<your 737NG profile name>] section in the FSUIPC4.INI file. In that section are listed the aircraft to be included in that Profile, by name or partial name. Make sure none of them will include the 777. Pete

Really? How odd. I've never had many problems with the airport files -- the Mag Var in those should be fine. And in any case some of my experiences seem to differ from what you say. The ILS for the freeware Prague airport for FSX was about 30 degrees out. I checked the airport BGL and found the author had made an error in one of the ILS definitions with a decimal point -- a magvar of 30 instead of 3 (if I remember the numbers correctly). This did affect the ILS alignment. Maybe those are corrected by Herve Sors updates, but at the time Ihadn't discovered those, so edited the BGL instead. So not all Magvar uses are derived from the Magdec BGL. I didn't know the Airport one was ignored for most purposes. Seems a damned waste as that seems to be the perfect place for the airport computations needed, and of course is why MakeRunways uses it. Except keeping airport scenery up to date if you intend to update the AIRAC data you use. For many years whilst I was flying FS98 I used a complete leather bound World Wide paper set of Jeppesen charts, my pride and joy at the time and my biggest expense other than the PC I ran FS on. In order to enjoy those to the full I never updated anything past the date of the simulator data. Everything matched all of the time. A frozen time warp, if you like. It almost broke my heart recently to give those cherished manuals up, but they had long lost their real usefulness (I gave them to a charitable cause). Those who really need up to date data all the time will really need to either stick to those airports which are relatively frequenty updated, or learn to use one of the airport editors to update their data. These days I do a bit of both. Regards Pete

Are you using the current version of FSUIPC, 4.921 or later? If so, you most certainly have something wrong then. Here is a test plug-in, written in Lua -- as I suggested to you. val310a = ipc.readUB(0x310a) ipc.writeUB(0x310a, logic.And(val310a, 0xBF)) i = 0 while i < 16384 do ipc.writeSW(0x089a, i) ipc.sleep(250) i = i + 256 end while i > 0 do --ipc.writeUB(0x310a, logic.Or(val310a, 0x40)) ipc.writeSW(0x089a, i) ipc.sleep(250) i = i - 256 end Save it to the Modules folder as, say "Test310a.lua". Assign a button or keyress to it (i.e. to "Lua Test310a"). Mae sure your throttle is disconnected and that you have no other throttle 1 assignments to conflict. Now use that button or key to start that Lua program and watch the throttle 1 lever. See it rise from 0 to max then go back down. Right? That's with bit 6 or 310A clear. Now edit that Lua by removing the -- at the start of this line --ipc.writeUB(0x310a, logic.Or(val310a, 0x40)) This will set bit 6 after the throttle has gone to max so that the loop bringing it back down won't actually affect the throttle at all. Save the edited file and run it again. This will prove that bit 6 stops 089A changing 088C -- just as it always has now for many years on many cockpit systems. I've tested here, of course, with 4.921f and 3.999z8, but this stuff hasn't changed in years. So, sorry, but something is surely wrong somewhere in your setup. Try enabled ipc write logging in FSUIPC's logging to see what might be writing to 088C directly without your knowledge. Obviously that would bypass the 310A setting. Incidentally, using this test I also proved that bit 3 does operate all throttle intervention as you originally thought it should but which I doubted. To demonstrate that change these lines: ipc.writeUB(0x310a, logic.And(val310a, 0xF7)) and ipc.writeUB(0x310a, logic.Or(val310a, 0x08)) [LATER] One possibility occurs to me. Did you read the part in the offsets list entry for 310A which tells you that the flags are cleared after 10 seconds or so (the actual time will vary, so don't rely on that exactly -- best to refresh every, say 5 seconds -- in the second loop above you'll notice the flag is set every loop). This is done so that the user doesn't permanently lose throttles because some program has crashed or quit after setting the bits. Maybe you are only setting it once, perhaps when the A/P switches on, and not refreshing it? Regards Pete

Sorry, I don't understand any of that. What is the problem? Can you describe it in a language I'm familiar with? Perhaps in English or Lua -- you could test your ideas out with a Lua plug-in. That's one of its main uses. Pete

Well, if the MagVar is wrong in the Airport data, the MakeRunways files will be wrong too. There's really no such thing as a field "not being filled" because the records have a fixed structure and there's no way of signalling that the fields present do not hold valid data. Yes, but it won't change the label on the tarmac! ;-) Regards Pete

Yes. ALL THE DATA IS FROM THE AIRPORT DATA BGLs! As I did say already. The files produced contain the data the people requesting those files wanted. They wanted the Magnetic Heading, so the program computes it By "real" you mean "current" presumably. You'll need to update the scenery if you want everything to match. I tend to only fly commercial or recently made freeware airports and they are more up to date than the originals, of course. I also only fly FSX so the oldest ones would be 2006 not 2004. With original FS9 airports you will of course notice these differences. Either you have to update airports, or stick with old AIRAC data. You can get quite a lot of fs data updated by using Herve Sors files, which he keeps level with Airac releases. Have you tried those? http://www.aero.sors.fr/navaids2.html. Mind you, I don't think even he does the runways and ILSs. Runway numbering is definitely an airport editing job. Pete

You'll need to be specific as to which data entry in which of the many files. However, where mag var is included it is direct from the airport data in the scenery BGLs, as those are the only files being processed. If you are using out of date scenery but up to date MAGDEVs then there will of course be discrepancies. Runway names are exactly those in the BGLs -- changing the MagVar does not automatically change runway names, you have to edit the airports to do that. Of course programs reading the magnetic runway heading and the associated magvar can therby compute the True heading and re-adjust for a different prevailing MagVar from yor MAGDEC file. This won't change runways numbers though. Pete

You posted in the "User Contributions" subforum which is for, er, contributions by users, not requests for help. I moved it to the Support Forum where it may be seen by someone who can help. You might also like to investigate the Subforum on the FSUIPC Client DLL for Net. Paul Henty's work makes things a bit easier for beginners. Pete

Well, there's bit 2 in the sound control offset 3122. You can find offset details by simply searching the Offsets list installed in your FSUIPC Documents folder. Search on "Marker". However, as far as I recall, changing that bit simply causes FSUIPC to use the control you say doesn't work for you, so I'm not sure it will help at all. Maybe ProSim support can help? Pete

Did you try the obvious one, "Marker sound toggle" at all? Pete

Aha! So it is a PFC 737NG cockpit, similar to the one I originally purchased -- though mine has been much modified with all sorts of changes by now. So are you saying the trim wheel simply does not turn when the A/P is in pitch modes when it should? If this is what you mean, have you tried "starting" it by giving it a little turn when it should be turning by A/P control? Because there is a known problem with the PFC motor control which PFC have never been able to fix -- the A/P control of the trim motor needs a helping hand, a starting turn of the wheel by the user. As far as I know this has always been the case ... mine has never 'auto-starte' from power up, but once it has started it operates okay for the rest of the session. Regards Pete

You cut off the first lines of the Log which shows the Version Number! Please do not do that! Anyway, it illustrates what I said. FSUIPC is working fine, but Simconnect is stalling: One thing which actually does show what might be one reason: FSX seems mightily overloaded. The average frame rate for the first 6 minutes (almost) was dismally low -- unflyable, I would say: You appeared to have stopped it to go into Menus (?) and reloaded the flight: Then things carried on and, again, SimConnect stalls after another 5 minutes plus: Again it recovers, though something reloads the PLAN file ... twice! And again things carry on for another 5 minutes plus -- and again a PLAN file reload, twice: but this time it only runs for 87 seconds before stalling. Then 13 seconds, then only 1 second, then ... 5 minutes plus, again, several times, each with double PLAN reloads, until finally the stall is unrecoverable for several reties, but then okay again! etc etc. And a dismal average frame rate too: So, something you are running is doing things, probably via Simconnect, which is making a real mess of FSX's operation, and it is probably all wrapped up with this double PLAN file reloading. Maybe it is somethgng in that Plan file which causes a problem, but that seems unlikely. If that ACARS program is the only add-on you are running then it must surely be the culprit. Try without. I can't really help more than this. FSUIPC is not to blame, it is trying its best. Something else is truly clobbering your FSX performance. Sorry, I really cannot investigate other folks' programs. I suggest you ask their support. But try without it so you can see if that's the problem. Of course I'm assuming you are using no other add-ons or add-ins. I don't know how you are flying "on-line" but maybe therer's some other program involved too, like FSInn or Squawkbox? If so you might need to check that too. Regards Pete

Is that all there is for the device? No details of report lengths, input and output values etc? Can't you show me what "combinations" you tried? As far as I can see there's only Vendor=0x0D59 Product=0x0120 or Vendor="TRC" Product="TRC 32DIGITAL IN 00" though you could shorten the last to something like Product="32DIGITAL" if you wanted. Providing it's unique. Pete

FSUIPC never "closes". If SimConnect stops sending it data for too long it will attempt to reconnect, and will continue to do so until successful. Please check the FSUIPC4.LOG file and see these attempts in action. If it never recovers then, yes, its operation cannot continue and you won't see the entry for it in the Add-Ons menu. But if it is that drastic then you really have something very badly wrong. Not that i know of, but you provide no information at all. What version of FSUIPC (if not at least 4.921 then please update). Is FSX fully updated? Show me the LOG file please. If SimConnect is freezing or crashing, then nothing FSUIPC can do can fix that. You need to find the reason. Does this ACARS system use SimConnect? Could it be a problem with the TCP/IP protocol used on your on-line link -- SimConnect uses TCP/IP too. You probably need to go through a process of elimination -- see if yiu ever get these freezes when not flying on line, or just not using ACARs. Pete

I understand it uses a serial interface, otherwise you would not be using PFC.DLL. But I don't know what the hardware IS! Is is a 737NG cockpit? Or some other console, or a collection of individual pieces. I just have no idea what you are talking about, don't you see? PFC have made all sorts of things with serial interfaces. So you have some sort of motor-driven trim as well as rockers? So now perhaps you can say what the problem is, because I've not understood that yet at alll. Sorry. I don't know how you'd determine this. Pete

He might be able to use SPAD. http://fstools.weebly.com/, but Saitek should support him. It's their job after all. Regards Pete