Alpin-Flier

Please find enclosed a commented log file for all new NGUx vars. The Aux fuel switches (only used in B737-900ER) also work fine. Good job!! Please let me know, which of the other NGXu vars could be critical, so I can test them in the same way. Urs Edit: Hi John, just saw your post. These are really good news 🙂 FSUIPC5_NewNGXu.log

Dear Pete Yeeeeeeeeessssssssssssssssss!!! You did it. 😃 😄😃 The whole new block is working now. Even the Flight and Land Altitude windows work, including the negative sign. I was preparing an Excel list to ease design, not needed anymore now, but I think, it is still useful (see attachment). Tomorrow I will check also the new fuel offsets, because they are only needed in the B737-900 version, that I never used up to now. And also check other data areas and then send a log file, if it looks reasonable. You are right with the difficult mouse control on certain panels. I think it has to do with screen resolution, focus, full_screen and similar stuff. I use this only on my test place with 3 monitors in viewgroup mode. Some panels inside this window (e.g. FMC) work fine with the mouse. Of course, I also prefer my homecockpit downstairs. Thanks for all the good work and best regards Urs New Offsets NGXu.xlsx

Yes, really strange, if you did not "offset offsets". For the moment I go on with the original 154. And I tested now also all three AFS servo commands during a flight. So I found A/T in 6C70 (as said before), Pitch in 6C71 and Roll in 6C72. They are shown correct with 0 and 1. Then at 6C73 the booleans for the busses start. 6C6E and 6C6F seem to have no function. Yes. You are at the holding point for runway 28 in Zurich, ready for lining up. And it is independent from an earlier panel state. So engines should run, no warnings. But set park brake, before you go on. Good practice for pilots, who want to survive when they try something..😄 Yes. But you can change it in the FMC for Cold'n Dark, Short (for short flights) or Long (for long distance). Up to now I used only short. Urs Edit: Reading again through the last posts I think to know the reason for the "wrong" offset. I made that test with version 153i.

Not really correct. The log shows 0C for the higher byte, E5 for the lower. So take C as 12: 12 x 256 + 14 x 16 + 5 = 3301. There we are... Lets start from the actual dll version (..154) again. The correct ADF value is found in 6C6C (not 6C6A). Then the hex values in 6C6C and 6C6D are correct: "07 6C" for 1900, "0C E4" for 3300, "44 5C" for 17500 Then three booleans on 6C6E, 6C6F and 6C70 follow for the ATS servo commands. I can check at the moment only the AT command on 6C70, it works fine. Then 16 bus booleans follow to represent different bus states. They work all correct up to 6C7C. But then there is no signal any more. All bytes on 0, no influence from the sim. This is also valid for booleans following on top of the busses. There is some strange inputs on 6C8D (toggles between 0 and 48), 6C8E (0...145) and 6C8F (0...65). I think these are the Flight and Land alt values. But dialing these values does not influence the offsets. So something goes wrong from 6C7D upwards. I think you shifted offsets for test purpose in versions 153g, 153h and 153i. So I did the tests above again with the official 5.154 version to avoid confusion. You can take any plane in P3D as default at start, but not one from PMDG. After this, you can select the PMDG, by aircraft or scenario selection. When you want to change between PMDG aircrafts without leaving P3D, select the default aircraft inbetween and then again the PMDG. That seems to work fine. It is not necessary to start the raptor or your other default plane. But the start screen must show your default first. PMDG explains this so: When showing the start screen, some SW loading has already be done in the background. Well, I can understand that. But you told me also not to be interested operating the PMDG, just to have it ready for tests. And so a plane with running engines (of course !) on the runway, but with park brake set, gives the easiest access. This is also recommended for the first tutorial. Unfortunately the NGXu has no "tutorial 1" scenario any more (as NGX had). But it should not be really a problem. By the way, I can tell you, that the PMDG NGX is worth to deal with. It seems that I have a default config for test002. You can select the panel state in the FMC: Menu / PMDG Setup / Panel state load Urs

Oh, this explains a lot. I will help as much as I am able, of course, to sort it out. This was with the new dll's, you sent me. The original (..154) made a lot of crazy outputs. I have seen, that changes to the ADF were visible in the log-file at 6C80. So I wanted to see how the frequency is shown in different formats. And as we can see, U16, but also U32 show the correct result in decimal. The hex format shows 0xCE5, but the log file shows 488359 Offset 6C80 = E5 so it must be a part of the correct value. So I aks myself, how the log file treats formats of the vars. E.g. a change from 3300 to 3301 is only shown in 6C80. The rest, probably at 6C81, does not change, so it is not shown in the log. This is confusing. But perhaps I am completely wrong. I made now a test with the original version (6C6A for ADF) producing high decimal numbers. But shifting to 6C6C and U32 format I get the correct frequency! The lower part of the whole data block seems to work. Problems start at 6C7D. Is it a question of different data formats at different offsets? Well, I am not very experienced with SW... To start the NGXu, begin with the raptor (default), then change the aircraft to NGXu (not as scenario). It should be at the preselected runway start position with running motors. Don't select any cold and dark, because then you get warnings (e.g. battery discharge) and must start APU and connect busses. Alternatively: I send you my test002 exemple, that you can put in the Documents/Prepar3d v4 Files directory and then select it as scenario. I hope this works. Urs test002.fxml test002.wx

I start always with 3300. Now I made some test with different formats. You can see it in the joined log file. I increased the value to 3301 and then back to 3300. No idea, where the long number in your test block comes from. I use FSUIPC for about half of my cockpit without any problems 🙂. The other half is Opencockpits stuff controlled via SIOC and OC4BA. For me as an engineer it is very interesting knowing both platforms... Urs FSUIPC5.log

That sounds strange, but I really can see the correct frequency in that window (in the log file too) and I also don't know, how the strange value is converted to the correct frequency. That is very kind of you. Thank you so much for the extensive cooperation. Since I need only two values, that are shown correctly in SIOC, I will send them from there to FSUIPC using two dummy vars and read then these vars from FSUIPC into my other HW driver to control "Takeoff Config" and "Cabin Altitude". Not very elegant, of course, but effective. Thank you for all your help and let me know, when I can test some issues for you (and me, of course ;-)) Now it's doggy time. All the best Urs

I made a test on ADF. I can put offset 6C80 in the first specific value check on your log window and give it the format U32 and then activate the FS window. So the value is shown correctly. Urs

I tried my best... This is the sequence I tried. May be that there is an additional Option call inbetween. My brain is not the best any more... ADF at start on 3300, flight alt on 10000 ft FSUIPC Options ADF changed to 10000 FSUIPC Options TOGA FSUIPC Options Battery switch off, then on Standby Switch off, then on FSUIPC Options CVR on, then off FSUIPC Options change flight alt from 10000 to 11000 ft FSUIPC Options The required offsets are still missing resp. inactive. No outputs between Option calls. At TOGA I get the servo coupling command, but not the take off config warning. Urs FSUIPC5.log

This is the log file with the new dll. The wild outputs seem to have disappeared. I just put the weather to "clear skys". Or it is your new dll or the change in weather? Urs Edit: the first two lines after your test blocks are due to center fuel tank, that I had to switch off (working 6C91 and 6C92). Then the AT servo command is visible on 6C84. By the way: operating TOGA not only couples the servo, but makes also throttles go up. As a result the takeoff warning should appear. In the cockpit yes, but not in the log file. FSUIPC5.log

Funny! I also go outside with my dog (a 4 year old Husky lady) for long walks. Walking like that has often resulted in good ideas ... I hope I got your instructions well. Please find enclosed the resulting log file. Again many wild writes after start. Then I did two changes, the first on 6C70 working fine. The other change was the CVR Test, but there no output is visible, meanwhile I can see in the VC the lamp going on. Urs FSUIPC5.log

Let me send you a recent logfile, where you can see, that something strange happens to some offsets above 6C7C. I don't touch the sim, but there are wild outputs for a while. At the end you can see the correct switching for the A/T servo. Perhaps it helps... FSUIPC5.log

That's what I did. And so I could tell you, that 6C70 and some DC busses change accordingly. But when I trigger the "takeoff config annunc", then not any of the values changes. It looks like there is no offset above 6C7C changing its value. Also Flight and Land Altitude show empty fields resp. a 0, when changed from ASCII to number. Also dialing does not change it. The IOCP table has the same input order as you use for the new SDK offsets. You can compare most values by names. 1612 corresponds to your 6C6A. Please find enclosed the actual .h file. Urs PMDG_NG3_SDK.zip

Sorry, but understood and corrected now. Please find enclosed two screenshots, one at holding, the other with TOGA activated. 6C70 shows correct result now. Then several busses show a 1 and switch off, when they are down. But busses from 6C7D upwards show 0 instead of 1. 6C90 and 6C91 don't change and remain on 0. To allow a comparison, I add an SIOC screenshot, that shows the same conditions as the holding one. Please let me know, if I can make other tests. Best regards Urs

Sorry, Pete, I cannot load FSQ files, only FSI. FSInterrogate tells me to use a newer SW version. I tried to load it from your SDK site, but there is no change. And the Liljendal page refers to your page for downloads. Where is the clue? Urs

I made the FSUIPC console show all value changes from 6C6A to 6C97, as you proposed. So I can also see, what values change when I dial the stby of ADF. The result: Over the whole range of ADF here are only changes shown at 6C6C. At little changes only two digits ("01" "03" "05" ...), at higher changes 2 x 2 digits ("49 1D" "31 21" ....) This would confirm, that there is a two-byte shift, isn't it? I also made changes to FlightAlt and LandAlt, but the behaviour is strange: The first change shows: 6C7D B9 98 41 6C88 60 C2 AB 5E 88 3C 98 41 6C7D 00 00 00 6C88 00 00 00 00 00 00 00 00 and then changes are blocked (no response any more). I hope this helps. If not, I will make the FSInterrogate copy. Urs

The first value at 6C6A works fine. But then it seems, that offsets aim to wrong values. E.g. when I couple AT servo (by choosing TOGA), then 6C70 changes to 1, instead of 6C6E. Two DC busses (6C71, 6C72) show a 0, meanwhile they should be at 1. "Cabin altitude warning" at $6C8E outputs 48, and "Takeoff config warning" at 6C8F outputs always 0. NGXu SDK outputs the values correctly as I can see using another parallel program (SIOC --> IOCP console). But I need the new values from FSUIPC due to my setup. Any idea how to proceed? Can I do some other tests? Thank you so much and best regards Urs

Hi Pete I use now the actual FSUIPC version 5.154. In my NGXu homecockpit I installed the new annunciators for "Takeoff_Config" and "Cabin_Altitude". But I don't get these outputs on $6C8E and $6C8F, meanwhile I can see them working in the VC view. I checked also with FS_Interrogate. Output values remain always on 0. Can you help me? Thanks a lot and best regards Urs Meyer

Hi Thomas Yes, these are the correct event values. But I must use 8192 for power up and 16384 for power down in the parameter box and switch on the repeat function. Actually I leave the levers as axes and define an additional range at the end, where FSUIPC sends the parameter 8192 repeatedly. That seems to work fine (up to now 😉) Best regards Urs

Hi Thomas Of course, you are right. To make it more real, I should use individual controls. I already found this in the PMDG SDK: #define EVT_CONTROL_STAND_REV_THRUST1_LEVER (THIRD_PARTY_EVENT_ID_MIN + 680) #define EVT_CONTROL_STAND_REV_THRUST2_LEVER (THIRD_PARTY_EVENT_ID_MIN + 681) I will make tests with them. Thanks again and best regards Urs

Hi Thomas Thank you very much for answering. I make some precisions: My setup uses the possiblity in FSUIPC to separate throttle and reverser levers. Throttle levers 1 & 2 and reverser levers 1 & 2 are programmed with "send direct to FSUIPC calibration", then Joystick calibration page 3, checkbox "no reverse zone" is marked. So the throttle levers send values between 0 and 16384 to the sim, meanwhile reverser levers send 0 to - 4096 to the sim. That works all fine. But after touchdown I can take the reverser levers immediately to the max position, because there is no mechanical blocking during reverser opening. When the reversers are ready to accept high power commands, there is no data change any more and therefore no commands for high engine power. But in fact, with your proposal I can solve the problem. The reverser axes work normally, but with the additional security, that in the end position of the levers the thrust is granted after some seconds. Perfect !! Thanks a lot and best regards Urs

Well, I just learned some minutes ago, that the problem arises from my control stand, that does not offer the following function (found in the PMDG manual): "Reverse thrust lever is blocked at reverse idle position until related thrust reverser is more than 60% deployed." Unfortunately my control stand (and probably most of other users) does not have this blocking of the levers. Is there a solution all the same? Best regards Urs

Hi Pete My homecockpit with FSUIPC is working very nice, but please let me ask you for a solution of the following problem concerning reversers in my PMDG737NGX. When I operate my reverser levers after touchdown in one move to the end position (max. thrust), the reversers start opening, which takes some seconds. Then engines should go to the commanded thrust. But since I am already in the lever end positions, nothing happens (no data change any more). I must move levers out of the end position and then back. Or move the levers very slowly so that there are data changes still after opening. Not really smart procedures. Is there a way to avoid this and get the thrust position corrected after opening? Thank you very much for any idea. Best regards Urs

Hi Pete Thank you very much for answering. In general I can do very narrow taxiway turns , so I think, controls are correctly adjusted and work perfect. Then I tried the pushback with the internal FS function (shift P and 2). But the result is the same, so PMDG probably uses the basic function in P3D. I cannot check the standard B737 of FSX, because in P3D I don't have this airliner. I tried also another P3D plane with similar result. Then I switched off my Zurich scenery. Again a very big radius. I think there must be a fundamental problem in FSX/P3D. In 2011 there were already discussions about this problem. The only way out would be GSX (of course, not ASX). But to be sure I will ask P3D people. Thanks again for help and best regards Urs

Hi all It seems to be a very old problem, but I could not find any solution up to now. In the NGX I can define a straight distance and the angle (left or right) for pushback. But the radius of the turn is extreme, so my pushbacks end in the grass or a building in general! This seems to be an old problem of FSX and the same for P3D I use. On the other hand additional programs as ASX are told to solve the problem, so it should be possible. Is there a way in FSUIPC to get this radius under control? Thanks for any help Urs