Jump to content

Litjan

IXEG
  • Posts

    5,604
  • Joined

  • Last visited

  • Days Won

    404

Everything posted by Litjan

  1. Hi Fred, 1.) I doublechecked, and everything works as it should on my sytem. Make sure that the needle faces the "correct way" - the little "crossbar" points to the course that you dial in on the MCP. Here are pictures of the aircraft sitting at EDDF 07C, facing towards the FFM VOR (set on CPTs side) and the RID VOR (set on FO´s side) is on the right aft quarter. These are the indications on the EHSIs: As you can see both are showing TO when the needle´s tip (crossbar) points TO the VOR. 2.) I have no idea if that works - we use the standard X-Plane AI aircraft information to read and display traffic information...so if Global Traffic writes to those datarefs, it should work - maybe someone who has Global Traffic can chime in here? 3.) When using the IXEG, it is best to completely forget about the default X-Plane sound sliders, it may be necessary to reset them after exiting the 737, there is some crosseffect...we hope to completely move towards FMOD with the XP12 version of our aicraft...then we will use default XP sound and those problems will be gone :-) The airconditioning sound slider does work on my system, though. Cheers, Jan
  2. There is no dedicated information - the clock works like the real one... You can use the CHR button to start/stop/reset the chronometer. You can use the DATE button to switch between time and date display. You can use the ET (elapsed time) knob (bottom left) to start a long-term timer, it is independent of the chronometer (we use it to time total flight time). The knob on the bottom right is used to set the clock - RUN is the normal setting (it runs), HOLD is used to hold the time until the exact time is reached (i.e. 0 seconds after the minute) and the other two positions fast-forward through the time or date. Cheers, Jan
  3. No idea - one can find other (proprietary) material on the internet, but this stuff is so special. We pilots did not even have those as personal copies, they were on board the aircraft, only. They were issued by a department at my airline - the basis was performance calculation done with the charts from the Performance Engineers manual (climb gradients, etc.) You could do some basic tests yourself were you do some accelerate - stop testing at different weights and different temperatures. Use the "distance traveled" dataref in X-Plane to help you with that. You can also do the same (cut an engine at V1) to determine the net flight path profile. Now measure distance to obstacle to find the required profile and then you can do some ballpark guestimation at which temperature you still "could just make it" (add 0.8% to this for margin). Of course all of this changes with runway state, intersection takeoffs, tailwind, anti-ice on, etc... Cheers, Jan
  4. Hello Jose, often this is caused by using XPUIPC, the 737 is only compatible with one of the older versions - here is a link to a thread where someone else had a similiar problem: https://forums.x-pilot.com/forums/topic/18276-throttle-xpuipc-acars/?tab=comments#comment-156727 The power increase/decrease works fine without it - the only problem we ever heard of was with XPUIPC :-) Please let me know if that helps? Cheers, Jan
  5. I really don´t want to promise anything, but we will certainly look at it. Some sceneries have a very dense terrain mesh, so sampling this mesh takes more time and can be perceivable as stutter. This may become even more prevalent with XP12, if the mesh in it is increased in density - so we will have to do something about it ;-) Cheers, Jan
  6. Hello Xaver, normally you could enter the altitude restriction on the FMC and the VNAV would do the calculation for you - but this does not work reliably for our plane yet...we are working on it! For now I recommend the "mental arithmetic" method - the 737-300 also sports the "banana" green range arc that moved dynamically to show you where you will reach the selected altitude if you keep going at the current ground speed and vertical speed (so it is not perfectly accurate, but pretty close). I also include a reference table on the avitab that you can install for our aircraft (its free) that lets you refine the calculation pretty well. Here is a video where I show how to use it: https://youtu.be/hSemWBgRNnE Cheers, Jan
  7. Hi, I said this in another thread, I think. Derating a takeoff accurately is tremendously difficult - as every single runway needs a new calculation, dependent on runway length and obstacle path. Before we used computers to calculate the TASS, we had two thick folders in the cockpit with "runway weight charts" that we would get out for every takeoff and enter them with all the necessary data...a cumbersome and error-prone process. From experience I can tell you that most takeoffs that do not have an obstacle problem can be derated safely to 45 deg TASS, when runways get shorter (<2500m) you want to go to about 40. I can count the "full power" takeoffs (excluding contaminated runway, they are mandatory for those)I did in flying the 737 for 10 years on one hand...it is very rare that you are so limited that you can´t even derate a few degrees (like going to 35 TASS). Cheers, Jan
  8. Ok - now I found what is going on! The brake accumulator indicator in the "modern" instrument version is not hooked up to the correct dataref. If you switch to "steam instruments" it works. Thank you, you have found a bug! I will add it to the bug database and we we will fix it with the next version. I should have tested both instrument versions right away, sorry for that and thank you for being persistent! Cheers, Jan
  9. Hello Vitek, make sure that you turn off the hydraulic pumps (both engine driven and electrically driven). It works ok on my system - and if you deplete the brake accumulator, there will be no more braking (airplane will start to roll if parked on sloping terrain or if engines are running). The Fuel qty and le device test buttons don´t work right now - we are working on a fix! Here is a link to the "current problems": https://forums.x-pilot.com/forums/topic/17981-version-133-known-bugs-and-workarounds/ Cheers, Jan
  10. I always make it a habit to also add a date to the "name" of my device...like "Jans Laptop November 2020" - then you immediately know what to FREEZE when there is a Windows update that triggers the "new machine" thing. Cheers, Jan
  11. Is that one of those new hover-buses in your picture?
  12. Hi viman, I just checked on my end - the brake pedals don´t move when you press a button vor braking, that is true and I am not sure that has changed recently. They are tied to the analog axis for left and right toe brake. I will have to talk to Tom to see if we can add that. The brake accumulator check works with the keys for me, though. Make sure you turn on at least the battery switch to power the instrument, otherwise the needle will not move. Pushing B and V keys (repeatedly) will bleed the accu pressure down to the precharge of 1000 psi. Let me know if that works for you? Cheers, Jan
  13. Litjan

    Landing gear

    Hi Ken, thanks for confirming that! Cheers, Jan
  14. Litjan

    Landing gear

    It may well be that way on the NG - but my documentation for the Classic does not mention this at all. The Airbus 320 has a similiar interlock where you have to reset the "gravity gear extension" handle for the gear to work normally again. Cheers, Jan
  15. Litjan

    Landing gear

    Ermm - first time I heard about this? As far as I know the flap is just a flap - not connected to any logic. It just opens access to the handles (which are just wires connected to the uplock hooks). So if you have any information about the flap locking out the normal gear operation - I am always willing to learn! Cheers, Jan
  16. Thanks Torbinator, I watched the video and yes - the sound should diminish when you move the camera away from the aircraft like that! I am 100% certain it will when we switch to FMOD, though. Cheers, Jan
  17. Happy to hear that you got the speedproblem fixed! The fuel quantity test is fully driven by our custom lua code, so it can´t be influenced by planemaker. The fuel gauges work, it is just the test (going through different displays) that doesn´t work. I am pretty sure that the MEL would allow flying without it, but the poor maintenance guys would probably have to pull dripsticks before every flight (and have the fuel run into their sleeves!). Cheers, Jan
  18. Hello Fred, the EFM should be turned on for best performance - but the plane will fly fine with it turned off as well. Your problems have nothing to do with the EFM. We will have it "forced on" by planemaker in the next update. The test button for the fuel meter and the test button for the leading-edge devices do currently not work due to a timer bug which will be fixed with the next Gizmo release. Cheers, Jann
  19. Hi Fred, I would suggest that you watch my tutorial videos and try to mimic (refly) what I show there. Cheers, Jan
  20. Hi Torbinator, in general the first thing we do when we get these report is check the underlying nav data that is being used. We would need to know the provider (Aerosoft or Navigraph) and the navdata cycle. Quite often the data is not correct in the dataset - or the user is looking at outdated charts, or updated charts with outdated navdata ;-) You can often see this yourself if you look for the corresponding .xml file in the navdataset and then do a textsearch for SITEE4. You can probably read the xml and see if the altitude of 230 or above is encoded there. This is what it looks like in Navigraph data: </Star_Waypoint> <Star_Transition Name="GGAPP"> <StarTr_Waypoint ID="1"> <Name>GGAPP</Name> <Type>Normal</Type> <Latitude>37.533222</Latitude> <Longitude>-112.134619</Longitude> <Speed>0</Speed> <Altitude>23000</Altitude> <AltitudeCons>0</AltitudeCons> <AltitudeRestriction>above</AltitudeRestriction> <Flytype>Fly-by</Flytype> <BankLimit>25</BankLimit> <Sp_Turn>Auto</Sp_Turn> </StarTr_Waypoint> I can see that the 230A is present (also in Aerosoft) and I can confirm that it is not depicted in our FMS when I load the STAR, so it is probably a bug in our software. This will receive close scrutiny in the VNAV rewrite, so it is probably not necessary to report these problems now. The curved approach problem depends on the RNAV capability of the (old) 737-300 Classic. It is not capable of RF approaches (radius-to-fix) - which defines the circle to be flown. Therefore when you see these letters on an approach chart: RNP AR APCH, RF required - it can not be flown with our aircraft- in fact I can not even fly ith with our modern A320s, we can not fly AR (authorization required) approaches, but we can fly RF, of course. I think for now there are normally alternative RNP procedures provided, because many older planes can´t fly RF. I will talk to Tom, maybe we can add that capability to keep our plane abreast of modern development, I am not sure if the real Classics still flying are capable of those approaches, though. Cheers, Jan
  21. Yes, I reproduced it as well... thanks!
  22. Hello nicotum, very sorry that you encountered this problem! We will try to recreate it and hopefully fix it soon. Thanks for your report! I will get back to you if we need additional info! Cheers, Jan
  23. Thanks for getting back to me on this - normally we are careful to "limit" the values that you can put into fields, but there is always the chance that we missed something. We are always thankful for hints and feedback on how to improve our plane, so if you gain any additional insight in this (or any other) matter, please let me know! Cheers, Jan
×
×
  • Create New...