Pete Dowson

Sorry, I need version numbers. Er ... they are text files. Text files zip up really small! Just got them. Only 6 Mb and 17 Mb each. They should be accepted separately! In any case you put two ZIP files in one ZIP file, doubling the size! And there are two taxiway files, labelled for the MakeRunways version. But only one set of Runways files! Anyway, I see they are different. In fact the later one is larger, so has more in it. I'll see if I can make time to look tomorrow. Perhaps you could meanwhile supply the missing Runways.txt file (the one you didn't send, which might be useful as that is effectively the log of what MakeRunways does. Are both sets made at the same time -- i.e. no scenery updates in between? Pete

Am I right then in assuming that the software you are using cannot change an individual bit -- i.e change just one 0 to a 1 or vice versa? In the Lua library supported by FSUIPC there are "togglebits", "setbits" and "clearbits" functions which operate on bits. If your software doesn't support this sort of thing, see if it can do logcal "AND" and "OR". These are operations to exclude bits or set them without changing other bits in the same byte. The offset number, like 0D0C, is actually an ADDRESS. It is the address of a byte of memory, real memory in your computer!*** Changing the value within a memory address doesn't change the address, as you seem to be saying. That would be like your postman only being able to post one letter in your house because the next would go to the next house, and so on. I think maybe you need to learn more about how to use your software, because that's really where your solution lies. Perhaps there's a Help forum for it, or at least for the hardware you are using it for? If your software allows you to send keystrokes, then an alternative, though messier than the logical solutions already suggested for you, woud be for you to assign keystrikes to the Offset Togglebits control (it's in the FSUIPC assignments dropdown), with x0D0C as the offset (the field shown as such) and parameters 1, 2, 4, 8, 16 ... 512 as already listed for you. Togglebits would toggle the light on and off Alternatively if you are using latching switches you can use Setbits and Clearbits to switch them on an off. But that would of course use twice as many assignments and corresponding keystrokes. There are ways of sending keystrokes via offsets if your software can't send them -- please check the offsets list for details. Pete *** to be exact, the Offset is literally the offset from an address, i.e. the value to be added to a known address to get the actual address. This is how the term 'offset' came to be used. it it literally the offset from someplace else, fixed inside FSUIPC's memory.

It is ALWAYS 0D0C for the light switches. Different bits are within that word (bits 0 - 9) for each light -- remembering bit 0 = value 1, bit 1 = value 2, bit 2 = value 4 ... up to bit 9 = value 512. The value is 2 to the power of the bit number, shown as 2^9 = 512, for example. i'm sure you can find a calculator or a calculator App which will compute this for you, but it is just double (multiplying by 2) for each bigger bit number! You are continuing to make it so complicated for yourself. Please try to review more carefully what everyone has been trying to help you with! Also, I don't really think you visited that FAQ subforum thread I referred you too days ago, did you? If you did but didn't underrstand it you should have said so! Pete

0x3E5 = 3301 (3 x 256 + 14 x 16 + 1 = 3301, check yourself on a calculator. Note that in Hex A = 10 .... F = 15, so E = 14.). 0x3E4 = 3300 (one less). The "high" byte (offset 6681) doesn't change still 0x3. Only the low byte changes from 0xE5 to 0xE4. (Intel processors store numbers from the low prt to the high part. Some other makers did the reverse). Sorry, I am confused. 6C6C is not the same as 6C80 as before. Can you explain please? When you say "original version", are you talking about the official issue of FSUIPC5 (5.154) or do you mean something different? Is this mandatory at P3D start time, or can I switch from my normal plane to that first? I can only get the NGXu to run on my Piper Cockpit (another hardware cockpit) which currently boots into a Piper Arrow III. You mean start the engine in the Raptor first? I assume you mean motor = engine? Surely you only get battery discharge after turning on the battery. Cold and dark = battery off too! (I do know all about starting an 737 from cold and dark. i do it all the time in my NG cockpit! 😉 ). At least with cold and dark I'd know what to do. By default this thing is starting up in a crazy state!! Okay, thanks. I'll try this tomorrow. i'm taking the evening here off. I'm flaking a bit (old age. 77 this year, and starting to feel t!). Don't I need a "sav" file for the cockpit state too? See your PMDG\737NGXu folder. I suspect without that I'll get the same default state I'm getting now? Thanks, Pete

But but but! The 3300 and 3300 values occur in offset 6C80, not 6C60 as documented and mapped! 488359 Monitor IPC:6C80 (U32) = 3301 488359 Monitor IPC:6C80 (U16) = 3301 488359 Monitor IPC:6C80 (U16) = 0xCE5 488359 Monitor IPC:6C80 (U32) = 0xCE5 488359 Offset 6C80 = E5 489406 Monitor IPC:6C80 (U32) = 3300 489406 Monitor IPC:6C80 (U16) = 3300 489406 Monitor IPC:6C80 (U16) = 0xCE4 489406 Monitor IPC:6C80 (U32) = 0xCE4 If this is really at 6C80 instead of 6C60 it implies all of them above that are 32 bytes out!!! 😞 What made you choose 6C80, or is it monitoring it as part of the Monitor4 entry I gave you? If so why is it logging in decimal and hex? This is really weird. When did you decide it was the value at 6C80 instead of the documented one? BTW, I checked back to me previous tester's reports. he was using an NGX comparible setup, not using the new NGXu values. So you are, in fact, my first real NGXu tester! I'm going to have to continue until i get this working ... oh dear. Pete

I searched back in my correspondence to when this was tested for me by another user. This was in november last year. I made a little Lua file for him to use in tests. I attached it here. Please place it into your P3D Modules folder, then, in FSUIPC Options assign an otherwise unused Keypress to “Lua NGXuCheck”. When you’ve loaded the NGXu, use the assigned keypress. It should display, on screen, the values of certain offsets. these are also Logged. Here the log is like this: LUA.0: FUEL_PumpCtrSw(2) at 6461 = 0, 0 LUA.0: FUEL_annunENG_VALVE_CLOSED(2) at 6463 = 0, 0 LUA.0: ELEC_DCMeterSelector at 6473 = 0 LUA.0: FMC_flightNumber at 6614 = '' LUA.0: DOOR_annunFWD_ENTRY at 6C14 = 0 LUA.0: AIR_DisplayLandAlt at 6C88 = '' LUA.0: FUEL_AuxFwd A and B at 6C91 = 0, 0 They are all zero here because this was before i had any PMDG aircraft running. In your case these should reflect their respective switch or value settings. So please change each of them, one at a time, and use the keypress each time to see if it has changed correctly. I need to know any incorrect indication, or confirm they are correct. I’ve tried to choose indications which you should be able to change and check yourself quite easily. With switches the values are 0 for off, 1 for on. The DC Meter Selector goes from 0 to 7 or maybe 1 to 7 according to the selection. NGXuCheck.zip

In order for me to get this sorted out, could you supply some other files? Let me explain ... When I load the 737NGXu, after previously loading a simple flight with an aircraft in cold &.dark state, the 737NGXu starts up with electrical power on and most other switches on. The FLT ALT and LAND ALT momentarily show reasonable default values, then go blank ( - - - - -). After a few more seconds warnings and all sorts of sounds occur. There appear to be no pre-made flight setups for this aircraft. I would have expected to find at least some options, like to start cold and dark, or ready to fly, whatever. This is all from a fresh install, just registered. I noticed it talked about an "Operations Centre". Do I have to run a separate program to get the thing to be usable? (Sorry, I would read some of the documentation, but i'm not really interested in getting the program working, only in finding out why the data is all wrong). To make this less of a load for me (I've been putting off other things I should really be working on), is it possible for you to set the aircraft up in a decent way, with defined settings, so that I can start from there? I assume when you save a flight the NGXu state is also saved? I'd need the P3D flight file and any NGXu saved files to go with it. Would that be okay? I did see a COLD&DARK.fxml.sav file in its folder. I assume that should go with a saved P3D flight with the same name, so it is odd none was supplied -- at least none got installed into the Documents folder for P3d4 files. Thanks,Pete

There's been no changes to anything to do with taxi routes. If fact there's been very few changes over the years -- mostly additions in response to requests. What are the two versions of MakeRunways you are comparing the results of? Perhaps you can supply the taxi route files from the two so I can compare them? (The MakeRunways documentation will tell you which they are). Please ZIP them and attach them, making it clear which is which. Pete

Sorry, I don't know what frequency you have set. Which long entry contains the one you say is correct? Do you use any of ther other NGX offsets, i.e. the part which isn't new for the NGXu? If so are they all correct? I've managed to get the NGXu working on a different PC and I can now do the logging myself, but I cannot figure out why what I'm looking at is so wrong. Another problem is that, though i fly a 737NG myself (I have a 737 cockpit and use ProSim737 software for all the systems and displays), I have great difficulty trying to do things on the PMDG panels. It all seems so, er, clunky. Pete

I think there's another thread reporting this, though I can't find it at present.. I think it is something to do with the way the panels of certain aircraft work. FSUIPC merely relays your request to the PANELS.DLL interface in P3DDDDDD or FSX and returns the result. There's really not a lot it can do to verify the veracity of the value obtained. Maybe if it happens relatively infrequently, and 0 is an unacceptable value, you can discard such reads and try again? Pete

Well, the data FSUIPC is receiving from PMDG is definitely mapped okay. the first part of each of the added logging actually shows what the PMDG data has provided, at least according to the structure PMDG provide in the .h file -- that IS the actual structure used in FSUIPC. So, I can see no way forward. As far as i can see FSUIPC is doing exactly what it should be doing. I just don't understand why the data it provides don't match the document PMDG has published. Sorry, I'm not really understanding what you are saying. Do you mean the value 2109472 is correct for the standby ADF frequency you have set in the cockpit? I have found an install package for the NGXu I apparently used last year to get FSUIPC working. i've installed in into my development system copy of P3D4 so that I can test it all myself (again?) ... however it either hangs P3D4 solid when selected, or causes P3D to crash. Usually the former. This applies even if i load P3D with its default flight. I use Windows 7 Pro on my development system. i am wondering if the NGXu isn't compatible with Win7. However, i'm sure it must have worked okay last year when i originally tested it all. It's all very odd. (I've never had much success with using PMDG aircraft). Not sure how to help further with this at present. i'll get back to you if I can work something out. Pete

Okay. Here is 5.153i to test with. Hopefully the second part of the added logging will now work correctly. Please don't restrict yourself t making one change. Make a change (note for me wha it is) for each visit to the Options, so I get a different log set for each. Pete FSUIPC5153i.zip

The weather has nothing to do with this. Just entering the Options and Cancelling or OKaying out would make the log entries. No need to do anything whilst there. I have an error in the code I added, making all the "Results in .." values wrong, probably zero. The first thing I don't understand is that the ADF_StandbyFrequency times 10 is 2109472, making it 210947.2. No matter what units that's in it makes no sense. What was it set to? Even treating it a BCD (binary coded decimal) it makes no sense. I need to relate it to the displayed value. Note that ALL of the values listed in the "Actual NGXu ..." section are directly from the data supplied by the NGXu using the structure in their SDK h file. In other words they have not been mapped or otherwise molested by FSUIPC. It would also be very useful, please, for you to actually set the pressurisation and landing altitudes to some predictable (known) values so I could see those. The 6 characters are supposed to be 5 digits zero terminated, but neither are. I think the 01 is intended to be shown as a dash and 00 as blank, but again that isn't documented. So please set both and tell me what you set them to. Meanwhile i will work on the test code to make the secong part, the Mapped value, log correctly. Pete

Before taking the dog for a walk, I've added some extra logging, with more explicit values named and for both the data being received from PMDG and that in the offsets. Please rename your current FSUIPC5.DLL or save it somewhere, and instead put in the test one attached (it is 5.153g, a predecessor to the 5.154 you were using). This will log the information I need the first time anything in it changes AFTER you visit the FSUIPC Options. You don't need to do anything there, just call it up and exit, then make one change in the NGXu. This should enable me to compare exactly what the NGXu supplies and what I've mapped into the offsets. I have a feeling that possibly one of the calculations of the offset positions relative to the data supplied is incorrect. (I couldn't make a straight copy, which would have been easier and less prone to error, because then I would break compatibility for NGX users changing over to the NGXu). Pete FSUIPC5153g.zip [LATER] Here's another one, 5.153h. After the above test, please save me the log and run the same test with this version. I've juggled the mapping slightly to see what changes, if anything. Then please provide both logs. FSUIPC5153h.zip

I've got both the .h file and the LOG ready to look at tomorrow. I'm also going to search back for the details obtained by the original tester, last year to see which offsets were checked then. I'm pretty sure we checked both a couple of early ones and the two which should be easy -- the character strings for the pressurisation altitudes. None of those hex values being logged near or at the altitudes are ASCII caharacters for numerals as one would expect. It's late here. I'll be looking at it when I get back from taking the dog for a walk tomorrow. Pete

There is an option is P3D to disable devices altogether. Best to use that. Otherwise, if ever one of the connections isn't present on starting P3D but is there on a later start, or if a Windows updates changes things, P3D may think it is a new connection and mnake auto-assignments again. I think the option to disable all controllers is right at the end of the controller assignments options in P3D. Pete

Thanks John, maybe you can explain better than I. I'm running out of ways of saying it! 😞 Dad

Which aircraft is that? What is all that about? Why the reference on the left to "0D0D, 0D0E, etc"? As I keep saying, it is only the 16 bits at 0D0C which are involved. OD0D contains only 2 light switches, at bits 8 (Logo) and 9 (Cabin). Offsets 0D0E to 0D4F inclusive are not used (or may be used internally). Please refer to the Offsets list. Only set and reset one bit at a time in 0D0C only so you can see what happens. You seem to have almost random assortments of bits out of 12 starting in 0D0C and creeping up to 0D11. Why? Pete

That's really not relevant here. If they connect as two devices they are treated as two devices. If you have all the connections you need with only one of them, then only assign to that one. Why have you assignments to both? That can only possibly occur if you have assigned to device 0. FSUIPC cannot change the numbers in your assignments! Are you sure you have controllers actually disabled in P3D? My guess is that you are getting confused by P3D doing auto-assignments when it sees the devices. Pete

I wanted you to select the option to "continuously read" (bottom left on the QD window screen) and operate assorted things to see which ones actually change each time (onr change at a time please to avoid confusion). It's the only way to actually locate the correct offsets. A static view isn't so much of a help as you telling me which ones are changing correctly. I don't know IOCP and i'm really not sure what it is showing me. The other thing that occurred to me is whether PMDG updated the NGXu after the SDK I received was made (right at the first release), so, in order for me to check that, perhaps you could go to your PMDG SDK folder, find the file "PMDG_NG3_SDK.h" (which is the name of the one supplied to me), ZIP it an attach it for me to cpmpare. Pete

I am using the one from our page -- the one included in the SDK. It has not changed since then! FSI files are those which provide information for the main display, NOT the separate windows. I think you are not following my instructions. Go to the FSInterrogate menu. See the "Windows" entry, 4th one from the left, between "FlightSim" and "Help"? Click on "Windows". You will see a list of QD windows ("Quick Data"). Select any one, then use the Load option to load the FSQ file I provided. Pete

Not sure. I'll make n FSinterrogate file for you assuming that and you can test more easily. None of that makes sense I'm afraid. [LATER] Here's the FSQ file. Put it into the FSInterrogate folder. Then you can load it into a Window (via the Windows menu then "Load"). Then you can select (highlight) all the data entries and opt to read them once or repeatedly, to see changes. You can try adjusting the offsets up or down to see if you can get better matching. Note that the twp offsets I've tabulated beyong 6C97 may not react -- depends if the FSUIPC mapping finishes where documented. Pete NGXu Offsets FSQ.zip

Only the [JoyNames] assignment, i.e. This next part I don't really understand: FSUIPC cannot "randomly switch" -- unless Windows is generating different IDs andGUID's each time. Are you unplugging or disabling the devices randomly? Windows is a bit pernickity with that sort of thing. Additionally If you want all your assignments on 1 assign to 1 not 0, and vice versa. The actual assignments do not change except by your action in the assignments tabs. Only the device identifications (JoyNames) may change. If things are likely to change you should be using Joy Letters in any casde. Please see the chapter in the User Guide about that. Pete

Which default aircraft has these? You are completely misunderstand the use of bits as flags I'm afraid. First, there is only the 16 bit offset, 0D0C. This does encompass 0D0D as well, because 16 bits occupies 2 x 8 bit bytes. Second, each individual bit in 0D0C operates oen light. Please try to get to grips with what a "bit" is. It is a value which can only be 0 or 1. There are 10 of them being used in 0D0C. Please review this FAQ subforum thread :

Yes please. First, from the first thing you said ("6C70 changes to 1 instead of 6C6E") try looking at the value after 6C6A as if they are all 2 bytes further on (i.e add 2 to each offset). See if that gets you matches all the way down the list. If so, skip the rest of this ... Second, you could use FSInterrogate's memory display option to display all of 6C6A - 6C97 in hex, and make a copy of that for me to see. Try to set as many of those values to something you know and list them as far as you can, so I can try to match them up. Third, if none of those prove fruitful, or you find it too difficult to tell, I'll make an FSInterrogate file for you to load in one of its Windows so you can monitor the vlaues in their proper format, and more easily make adjustments to the offsets in the Window until the values match what you expect. If there is really a mis-match then either the NGXu isn't matching what I'm told in the SDK, or, probably more likely, I have made an error and my previous testers weren't thorough enough! Pete