Jump to content

Litjan

IXEG
  • Posts

    5,134
  • Joined

  • Last visited

  • Days Won

    338

Everything posted by Litjan

  1. Hi Daniel. there is some variation between airlines, but most common use for takeoff would be: 1st bug to 80kts, second bug to V1, third bug Vr, set speed cursor to V2, fourth bug to V2+15 (this is the speed that is minimum for going over 15 deg bank), fifth bug to 170 (for flaps 5 and 15 takeoffs), this is the speed to retract 5 to 1. For landing we set 1st bug to Vref, speed cursor to target speed, second bug to Vref + 15 (min speed for going over 15 deg bank) and i often set another bug right next to the second one if planning a flaps40 approach (as a reminder). Cheers, Jan
  2. Did you see the "descent helper" sheet that is available for the avitab?
  3. Hi Daniel, I did not check your calculation step by step, but it sounds about right. Naturally if you change your remaining distance to the airport you also need to change your angle of descent - the best way to do that is using FL CHG mode. VNAV will have a hard time regaining the path - as it descend steep to get back onto the path, it will overspeed and then pitch up - that is the "wavy" descent that you observe. VNAV descent will ONLY work well if you fly exactly on the planned path and never get too high - otherwise you need to revert to a more basic mode and do the math in your head (remaining distance x 3.3 is a good approximation). Viele Grüße in den Hunsrück, Jan
  4. Interesting! And you are correct, there should not be a CWS indication with FD as the commanded mode - just a blank channel. I will try to recreate and fix this for the next update, thanks!
  5. No, the reason for this happening were never discovered or reproduced.
  6. I am inclined to go with your suggestion - it is true that we often had the left pack running because it was not only safer (and a bit more quiet) for the baggage handling personell, it would also cool the cockpit a bit better (at the expense of the cabin cooling ). So I noted your suggestion and will try to remember to implement it for the next update.
  7. It has not been decided, but I don´t think so. I have to spend so much time here answering useless questions that I have to reap in the rewards for that somehow .
  8. I have not started upgrading the 737 for XP12, but it already "runs" in it. The other variants are not going to be part of the version 1 run, but we are not ruling out doing a V2 at a later time with greatly enhanced extra functionality and variants.
  9. There will be no change to the rain effects on the windows in XP11. The XP12 version will incorporate default rain effects on the windows.
  10. 1.) Not yet (MU2 project is not finished) 2.) The 737 project is done about 95%, I would say. Most notably some FMS work (VNAV, Holds) and 3D work remains. 3.) It is unknown how long it will all take. 4..) That is unknown, but I hope so for you!
  11. Thanks for the follow up - even if it wasn´t satisfactory. I don´t see anything else I or we could offer - especially since this kind of incompatibility does not seem to be widespread (you are the only one to report it, in fact)...which makes troubleshooting even more difficult :-(
  12. I think the latest does not work. This user: reported 2.0.4.7 working - so maybe 2.0.4.8 does as well. The XPUIPC program is not being actively developed anymore and if I understand correctly does some things that are not correct by X-Plane API coding standards - hence the interaction problems with Gizmo. Ben Russel - the developer of Gizmo - is aware of these problems but says that XPUIPC needs to fix it. I know that some hardware relies on XPUIPC to work correctly - but if you use an unsupported freeware program...there is always the possibility that things go wrong and there is really no one accountable to fix it. Good luck, Jan
  13. Hi Chris, thanks for letting us know! We are aware that the IXEG 737 does not work with the newest version of XPUPIC - so if you use that to drive your hardware throttle there can be problems with the throttle not working on the 737. However we have not received a single report about incompatibility with any SASL driven aircraft...and the 757 is a popular add-on, I think we would have more reports if this was a problem for all people that have both aircraft installed. Do you use XPUIPC? Cheers, Jan
  14. I know... You have noticed that we haven´t done ANY update in the last two years, so it is not like we neglected VR foremost... we neglected everything equally . I hope we can continue to work on the 737 soon. Cheers, jan
  15. Glad you have some success with this! When I flew the 737 we were taught to listen to the radio altimeter count down from 50... at 30 we would do a short "break" (yank back the yoke to break the sinkrate, hold new pitch attitude about 3 degrees MORE than what you had during the final approach), then at 20 slam the throttles all the way to idle quickly. As soon as you feel the wheels touch, rip open the speedbrake all the way - just in case the automatic deploy fails.
  16. I can see the movie now - as I suspected, you are not at idle thrust - idle thrust should be about 35% N1, it is a bit hard to read on your video, but you are at ca. 55% N1, so there is obviously something wrong with the way your controller axis for thrust is set up. You are also coming in with a solid tailwind, which will naturally extend your flare distance some more. I assume you are the same guy (Fiddle Sticks) that asked for help on the .org forum? As you are also not arming the speedbrake on touchdown... the third reason why this isn´t working for you. Here are some screenshots and a video how it is supposed to look. Approach speed should be Vref+5, bleeding off to Vref upon touchdown, you do this correctly. 737 touchdown.mp4
  17. Can´t watch the video as it is set to private. I also can´t provide private tutoring on flying the 737 due to time constraints - but if you float for "several thousand feet" with thrust at idle....either your thrust is not idle (bad hardware throttle setup) or you are not at Vref (wrong weight input in FMS).
  18. We are aware of that problem and are planning to increase it in the future for people playing at 4k! For now - consider it the annual eye exam you need to pass to keep your ATP license ;-) Sorry! Jan
  19. Hi! In one of the updates the displays were a bit "cleaned up" - the effect that you show on your pictures was kinda cool, but really a bit too intrusive. A real display is rarely that dirty, and if it is the pilots will wipe it clean pretty quick, because...we need to see stuff on those ;-) Here is what it looks like on my end right now:
  20. And once you turn up the rendering settings high enough to get HDR you can use the cockpit flood light (dim or bright) if things are still too dark. In addition you can use the map lights (over the pilots head) to spotlight certain areas of the cockpit (they swivel) - and if that is not enough illumination you can grab the flashlight (mounted to the side of the pilots) with the mouse and this will illumnate a small area around the mouse cursor to help you see stuff better. The real 737 has a light built into the control stand of the thrust levers that backlights the trim unit indicators, so they are a bit easier to see than the one´s in our plane. Thanks, Jan
  21. Hmm, that is too bad - but of course, there is still the option to remove your other plugins to test if they interfere. Cheers, Jan
  22. hmm - any Gizmo error can have unpredictable results on all systems. So as soon as you have a Gizmo error, consider the flight flawed! If you do, please post those with a screenshot and the log.txt in the relevant forum so we can see what the problem is. There should be no Gizmo errors on your flight at all - note that you can not change any altitude or speed restrictions in the FMS (yet).
  23. No, the real aircraft is pretty reliable when capturing the ILS - but then again you are the first one to report problems with this in 7 years of selling this aircraft and thousands of users flying ILS approaches with it. So this makes me believe that you are doing something unique - not wrong, but different from everyone else that makes you have these problems. It must be something weird that is confusing the capture logic - you could try to "reboot gizmo" before trying a new approach, this should clear out any data variables that the AP logic might have engaged from previous flights.
×
×
  • Create New...