Jump to content
The simFlight Network Forums


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Alpin-Flier

  • Rank
    Advanced Member

Profile Information

  • Gender
  • Location

Recent Profile Visitors

599 profile views
  1. Hi Jim Both platforms I use to connect my HW to the sim use the same procedure after start: They read HW switch states once after start (sim and FSUIPC already running). Then they send commands to the sim accordingly. If I need a synch later on, I must close the cockpit software (not the sim itself) and start it again. This is e.g. needed after you have loaded a new scenario with different resp. unknown switch settings. Urs
  2. I am not familiar with LUA, but I think to have found the solution with SC-Pascal, one of my platforms for HW coupling. I just add the following code in the main routine: WriteFSUIPC($3114,4,-1); // Synchronisation of Flap levers case ReadFSUIPC($3414,2) of 0:begin WriteFSUIPC($3110,4,76773) end; // set Flaps lever to 0 2559:begin WriteFSUIPC($3110,4,76774) end; // 1 4606:begin WriteFSUIPC($3110,4,76775) end; // 2 6653:begin WriteFSUIPC($3110,4,76776) end; // 5 8700:begin WriteFSUIPC($3110,4,76777) end; // 10 10747:begin WriteFSUIPC($3110,4,76778) end; // 15 12794:begin WriteFSUIPC($3110,4,76779) end; // 25 14841:begin WriteFSUIPC($3110,4,76780) end; // 30 16383:begin WriteFSUIPC($3110,4,76781) end; // 40 end; That is quite compact code and works fine up to now with my NGXu. If you would like additional explanation, let me know. Well, I think more of doing a completely new flight the next day, not to continue. Otherwise I save the actual situation as scenario and load it again. But this is sometimes quite critical, I agree. Anyway, now my sim follows the HW and that's what I wanted 🙂. Sometimes it is good to describe a problem, then the solution comes by ... Urs
  3. Hi Thomas and Pete Thank you very much for answers. Of course, defining a state with all things off and levers at idle does help. But I would really prefer a synch. I am sometimes a lazy pilot leaving the plane in some undefined state 😄. Just think about a long distance flight and then your wife is calling for dinner... at least my sim experience. All the switches and displays controlled by my scripts (SIOC, SC-Pascal) take over HW states and do a synch after start. But levers drive the sim bypassing the scripts. However I think, with a script snippet I can read the HW lever positions and send lever commands to the sim after start. Only after that lever changes send commands directly. What do you think about? Anyway, I will try this and tell you the result. Urs
  4. Hi everybody I need advice concerning synchronisation between homecockpit HW and P3D. My flap lever controls the P3D / PMDG_737_NGXu via FSUIPC. When I start the sim, its flap lever is not synchronised to the HW lever, until I move the latter. I know, this is due to the fact, that only changes trigger commands. But this is not really useful and even dangerous. Is there a workaround with FSUIPC to force the synch at simulator start? Thanks for any advice. Urs
  5. This is an error since longtime and was never corrected. The (dim) remark should be next to Open. During transit the lamp is highligted in the VC. By the way, I asked PMDG also to make the anti-ice-switches working the same way. But there was no success, unfortunately. I had to do it with script timers. Is's not really a problem. Thank you very much for the final version. I will install it tomorrow. Have a nice weekend Urs
  6. I did now an extensive test on most NGXu vars from offset 6420 upwards. I had also a special look to multiposition switches and displays. Gentlemen, everything is working fine, offsets are at their correct positions, values represented correct. There is a small correction in your offset mapping file: offset 6469 is not a boolean, but 0 for off, 1 for dimmed and 2 for highlighted. So I think you can go on with the corrected version. I will be happy to use it as first. It was an honour to assist you 🙂. All the best Urs
  7. 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
  8. 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
  9. 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.
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.