Jump to content

Calypte

Members
  • Posts

    25
  • Joined

  • Last visited

Everything posted by Calypte

  1. How many of these Twotters fly single-pilot-IFR?. In how many of those the single pilot interfaces with (almost) all of the switches using a mouse. In how many of these this single pilot operates a half-baked GNS GPS... Can you find at least a single real-world Twotter whose pilot is in this situation?
  2. To sum it up We have an anti icing that behaves somehow like inertial separator. But only on the left engine. We don't have inertial separator, because it is not modelled in 3d and this prevents us from using the separator as the vane that is invisible from the cockpit. But we have the inertial separator (at least its logic) connected to anti icing switch. But only for the left engine (as mentioned earlier). Couldn't we just have the inertial separator on both engines connected to the proper switch? Without the 3d model? For now.
  3. Tell me that this is a feature and not a bug and I will be quite happy. But it doesn't seem so. It is an unintended behavior that reasons couldn't be traced so we are left with "the default simvars". I compared several planes and it's Aerosoft's Twotter and SWS's Kodiak that show this behavior. The CRJ is much worse (check the screenshots). And most other planes I fly do not suffer from that. What I am worried about is a bug that will be caused by this and that will be even harder to explain (we all know about the issues CRJ has with its autopilot and how difficult or impossible they were/are to trace). This is a bug in a nav system of the aircraft. In the nav system that is actually quite buggy. Take a glance on two threads about radionavigation bug - seems unrelated but it is impossible to shoot a VOR approach using an outbound radial. This is why I think that correcting small bugs is important. And if we are to have compass deviation in MSFS, maybe it should be coded instead of bugged
  4. Older thread on the same issue
  5. It doesn't work fine. It is a random process that mostly works fine. But sometimes it just doesn't work. Today I flew something like 25 short flights. It malfunctioned on more than 5 occasions. It behaved differently than supposed, although I am pretty sure I know what should have happened. FD logic in this autopilot is seriously flawed and any deviation from the narrow procedure taken into account by the developer makes it malfunction. Please, do not ask whether anyone watched tutorials. KAP 140 is a pretty simple system. Manuals are available and many of your customers know how this system works - from how it is simulated on several payware aircraft in P3D or XP or from the real-world experience. It is a frustrating design choice to force people to unlearn how to use it and then to watch tutorials showing how to operate it in this rendition of a payware plane (mental note - this will probably change as the system is updated - if it is). I understand your explanation about the compatibility with xbox, but as a PC user and customer I would assume that this part of the market is also considered. Judging from the number of users complaining for the AP - this frustration is rather common. Unfortunately, unlike the real world pilots, I do not have a buddy sitting next to me in the cockpit and I do not have physical switches and knobs and I could really use a properly working AP when I depart an airport and need to setup my GPS.
  6. Let's use ADF knob as a reference (it seems more or less ok). 1. HSI knobs are way too fast CRS turns 360 degrees for 20 degrees of course selector rotation, HDG turns 360 for 30 degrees of heading bug rotation - inconsistent. 2. Altimeter baro knob - no rotation at all. 3. Radio altimeter - no rotation at all. 4. OBS knob (VOR Indicator) - even worse than CRS on HSI. Also - even shift+scroll requires like 25 scroll turns (full scrolling movement of my finger) on mouse to turn the CDI 180 degrees. Very difficult during instrument approaches.
  7. Cross Deviation Indicator on HSI (both HSIs) flips from one side of the scale to the other when selecting radials in FROM mode. TO works correctly (indicator shows deviation from selected radial). How to replicate: 1. Find a nearby VOR, tune NAV radio, switch CDI to VLOC. 2. Turn CRS knob to find direction to the VOR. It will be ok with proper deviation when set to something close to the current radial or its reciprocal. 3. Turn CRS so that the pointer points in a reciprocal direction (turn it 180 degree around). The needle will flip from far right to far left of the scale (or the other way around).
  8. Check it somewhere in Alaska (or any other place where magnetic variation is around 15-20 degrees). Somehow the magnetic variation is connected to this. The screenshots haven't been doctored - this is how compasses differ in PAJN.
  9. But the power loss is actually simulated partly. It is simulated on left engine only and the power loss occurs when engine intake anti-ice switch is flipped. I get 5 PSI drop on left engine when I switch it on.
  10. Yes. But at the same time this standby compass is used to verify whether your main compass / repeater or HSI indications are correct. This "instrument check" point in preflight checklist refers to exactly that. In this case I should just glance at these two instruments and say "instrument check, compass indication wrong, let's go flying, we have GPS"
  11. Fun fact. Inertial separator is simulated under "intake anti-ice" switch @Mathijs Kok Wouldn't it be possible to just move this feature to a proper switch?
  12. Central panel lighting is beautiful if viewed at a certain angle. But as you move pilot's head the shading changes significantly and straight lines appear where lighting disappears. I used red dots to mark the places where these strange lines appear. Check out how the angle changes shading.
  13. I am not commenting on the rotation, but on the indication which is off by several degrees
  14. Inertial separators are modelled in several aircraft in MSFS in the moded TBM (in the default too, as far as I remember), in SWS's Kodiak. Even the otherwise terribly simulated King Air has it. It is a bit confusing. Yes... I have found this statement: "Note that this is currently not modelled in this product". Which is clearly contrary to this statement: "As you can easily see, the Aerosoft Twin Otter has realistic engine displays for torque, RPM, and ITT. Furthermore, the inertial separator in the engine influences the engine parameters, just like in the prototype."
  15. C208B with magraina's Improvement Mod https://github.com/SheepCreativeSoftware/msfs2020-C208-Improvment-Mod It keeps correct parameters (almost - to 1,5% accuracy) withing the normal prop range.
  16. I don't understand your question? Both the HSI and the compass should indicate the same heading. Ok - there could be a slight difference to account for magnetic deviation of the compass, but the deviation is not simulated as far as I am aware and the deviation card you provided in the Twotter shows that it is 0 at this heading.
  17. I'm trying to get intake deflector to work, but I see no results. TRQ is exactly the same no matter how long I keep the switch in extend or retract position. Tested on the ground and in the air at various power settings.
  18. Compass shows slightly different direction compared to the HSI. HSI is correct (I compared the indications with airport charts). Compass is usually several (2-4) degrees off. The problem shows especially in places where magnetic variation is more significant (Alaska for example). Screenshots taken in PAJN. Runway direction - 265. HSI - 265. Compass - 269. I noticed a similar problem in CRJ.
  19. Power changes when prop RPM is changed from 96% to 80%. Incorrect, would not happen in the real-world. Do a simple test: 1. Set some cruise power. For simplicity set 80% power (96% RPM and 40 PSI Torque). 2. Note speed (after it stabilizes), Ng, Fuel Flow and T5 Temp. 3. Change RPM to 80%. 4. Note TRQ and the same parameters you noted a moment ago (speed, Ng, FF, temp). My values: At 96% RPM: TRQ = 40 Speed = 149 KIAS Ng = 90,5% FF = 299 T5 = 630 At 80% RPM: TRQ = 45 Speed = 146 KIAS Ng = 90,5% FF = 299 T5 = 630 What exactly happens here? Somehow by changing prop speed we: a) lost some power (as indicated on instruments) b) lost some speed c) did not change gas generator parameters a bit... Engine Power. In a free turbine turboprop (such as PT6A) pilot sets power with the power lever (in alpha range). Of the events noted above only c) is correct - as we do not change the position of the power lever gas generator parameters stay the same. Prop lever governs Ng, FCU in the engine selects a proper fuel flow for the selected Ng (hence no change in the fuel flow) and the temp stays the same, because the whole process does not change. And the power does not change. Because we did not touch the power lever. A bug: a) The plane lost some power, which is indicated on the instruments. Power can be calculated from TRQ and Np indications and max rated power will be achieved at max allowed RPM and max TRQ. Any power changes will be in proportion to the equation, as power = trq * rpm. Keep in mind that power is generated in gas generator and is (in a free turbine turboprop) unrelated to the prop rpm). So the power does not change (as explained above - I did not move the power lever, the same amount of fuel goes to the engine). If you calculate the power with TRQ and Np indications... you will see a drop of several percent when prop RPM changes. Somehow some amount of power generated in the gas generator... evaporated before it reached the power section. TRQ indication for 80% RPM should be (in this example and in my test conditions) 48 instead of 45. A consequence of a but: b) Speed change is related to the power change. This is correct. As the power dropped, the speed should drop too. But the power should not change (as all the indications for gas generator do not change). This may seem as a limitation of MSFS, but it is not. Currently available planes show that correct power changes can be achieved and no change in speed can be achieved in normal prop speed range. Speed change can not be explained with the change in prop efficiency. The prop efficiency does not change significantly in the usable Np range and the efficiency should not drop at lower RPM (it could actually increase).
  20. Someone stole the Course Selector Pointer from my co-pilot's HSI.
  21. With the experience of FSX/P3D Twin Otter I am very disappointed with the KAP 140 autopilot used in MSFS version. Aerosoft chose to use a buggy/limited simulation of KAP 140 provided by default with MSFS. Current bugs: - when engaged the AP sets VS to 0; real-world AP sets current VS; currently enabling AP during climb makes no sense as the AP will pitch down (or up when engaged during descent) - default roll mode for KAP 140 is "wings level"; not simulated in Twin Otter; currently when we engage the AP there is no roll mode at all (not possible unless faulty AP in the real-world); - arm button not functional; - alt button logic is incorrect; - altitude selection logic incorrect. I refrain from describing the logic of both buttons as the manuals for KAP 140 are easily available.
  22. Hi, I noticed several tiny issues with TOD time and distance displayed on MAP DISPLAY when window VNAV mode is selected. 1. For some reason my TOD calculations are often incorrect - time to go is greatly underestimated. Please check the image attached - you will find that ETA for both TOD and AAL is 5 minutes. But the distance is different - TOD is 9 miles further than AAL. 2. TOD distance is refreshed only once in several miles. My last readout was 9 NM right until I passed over it. 3. TOD appeared on my display only when I cycled WINDOW options in MFD MENU.
  23. I did a turnaround yesterday with no issues. ENCN -> ESMS -> ENTO. The only difference from what you described was that I went from APU to ground power and then powered the plane back from this state. But I don't think it was the change that saved me from the issues you hit. But, as the topic showed up and it is probably not our "problem" only - could someone share a proper flow or procedure for a quick turnaround, please?
  24. Same here (and same thing reported in my FB group). My testing procedure: - load flight (no matter where) - state does not matter (I tried full startup from cold and dark, I tried ready for taxi - the freeze happens every time) - select destination in FMC (I did not select anything else in FMC) - select dep/arr page - select destination airport - select approach* Tried this several times - position, selected airport and the approach selected do not make a difference. Avionics and tablet freeze. If in the air - aircraft responds to power changes and control inputs, but throttles in the model do not move. Navigraph database. CRJ purchased through the Marketplace.
×
×
  • Create New...