Litjan

You are close to an "inner marker" - it is a radio transmitter near the end of some runways that will alert aircraft on approach that they are about to see the runway (if they fly in clouds). You can move forward until you dont hear that sound anymore, fly from another runway or disable the sound by deselecting the "marker" audio channel on the audio selector panel.

Today some high altitude flightmodel testing for the conversion. The picture shows steady state at FL350 and M.74 with 46.000kgs. Book values (official POH) are: 82.8%N1 and 1009kg/h FF.

The first thing I would do in your case was posting in the correct forum, corresponding to the aircraft you are trying to fly. Good luck!

The engines start fine :-)

And initial testing is promising... IXEG XP12 initial testing.mp4

Thanks for the nice feedback and the solution to your problem! The 737 classic is the plane I enjoyed flying the most, and I hope it shows in our simulation...although all the credit of bringing it to life in the virtual world goes to Nils and Tom - they are the true artists behind this project. I use the speedbrake in our simulation exclusively with the X-Plane commands for "Speedbrake - extract one and Speedbrake extend one". This gives you perfect control over all the necessary steps of movement (down, armed, flight extent, full extent). Cheers, Jan

Hi and thanks for the kind words! I suspect - and this is just a hunch - that the speedbrake does not registers as "completely down", or the flaps are not "exactly" in 1 or 5 - this sometimes happens with hardware "axis" assigned to those functions, instead of buttons or keyboard presses. To "test" this you could a.) display the values for flaps and spoilers using the "data out" function - it will show you the exact values for those flight controls in green numbers on screeen and/or b.) unassign thoses axis (temporarily) in the setup of your Honeycomb hardware and operate those controls with buttons or key presses (or the mouse in the virtual cockpit) and see if that makes a difference? Another thing to test is pushing the thrust levers forward really quick during taxi-out before your second take-off - just to test for the takeoff warning - it beats finding out about the problem earlier than in the middle of your take-off run ;-) Let me know how that works? Cheers, Jan

There is nothing special about the way we model the nosegear steering on our 737, it is just default X-Plane logic. So if you can do it on the default 737, for example, it should work on our aircraft, too. Cheers, Jan

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

Did you see the "descent helper" sheet that is available for the avitab?

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

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!

No, the reason for this happening were never discovered or reproduced.

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 .

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.

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!

Just like in the real aircraft!

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 :-(

Those look excellent!

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

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

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

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.

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

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).