anthony_d

5 Months later, I've used the aircraft without problems just by making sure my prop levers weren't set to cutoff when the aircraft was loaded. However since then I've now gotten into aircraft development myself (RW Designs Twin Otter), so I've learned a thing or two about datarefs. The problem dataref is this one: sim/cockpit2/engine/actuators/prop_rotation_speed_rad_sec[0] / [1]. Now this seems to read the position of the prop levers upon aircraft load only, and then this value is frozen for the rest of the flight with no possibility for a regular user to change it. It seems it can either be one of two values: - The value of the prop levers upon startup - A value prescribed by script on the first frame. On any other aircraft, this dataref will freely change with the prop handle position. But not here, and the consequence of the dataref being close to zero (because of *any* detectable noise on the prop handle), is that the engine doesn't start. Do this test: 1. Load the aircraft up cold and dark. 2. Set the dataref "prop_rotation_speed_rad_sec[0]" to zero, using dataref editor. 3. Attempt to start engine 1 via the usual procedure. I'm confident now that you'll be able to reproduce the problem of engines not being able to ignite.

If the aircraft is loaded with a very low prop value baked in (less than 20), then that aircraft engine will never start. This is 100% reproducible. No I can't reproduce the scenario without hardware. That doesn't mean the problem is my hardware. Why should noise on the condition lever be baked into the prop value when the aircraft is loaded? That's a problem with what your code does in response the hardware input. Speculating here, the prop values are probably taking a (very small) change in hardware input as an override to the default prop values. But it's certainly seems daft that hardware inputs that are inherently dynamic have an influence on values that remain static for the rest of the flight. I suggest you try it with your own hardware inputs for the prop lever. The original poster also suffered failed engine starts, so there is potentially at least one other person out there. And it has certainly been a historical problem that I've read about in these forums. You've previously talked about manipulators being updated in version 1.5.2, which I understand are interfaces in the virtual cockpit, not the hardware. Therefore I'm not so confident in your statement regarding it being a moot point. I have every expectation that this problem will persist into 1.5.2 unless the problem is acknowledged beforehand.

The end of a failed start is when I pull back the condition lever to the cut off position after I've waited about 15 seconds or so. That will switch off the starter (which I can hear winding down) and I therefore consider that to be an aborted starting sequence. I've looked a general data outputs for propeller and mixture settings, and only the mixture value changes (0 to 1) between the cutoff and start lever positions. I haven't looked at datarefs at all. In my line of work, I'm dealing with 4-20mA analogue inputs into logic, but then I have full access to see what logical behaviours are attached to the input so I can fully see what's going on. So yes, I do like to analyse things down to a point where there is a pathway towards implementing a proven solution. I'm guessing only you can see what's going on in your logic. I've measured the noise on the condition lever and it's around 1% of total travel range. That doesn't seem like a troublesome amount..... With the Saab, all I can see is, once I've got one start failure on my engine, I can attempt to restart that engine as many times as I want and it simply won't start (regardless of what I've tried, hardware disconnection or not, depowering the aircraft or not, standby fuel pump override or not). That tells me that something in the logic has latched, but what that something is I can't tell. If I knew how it got latched, and how it could be unlatched then I guess we've figured out a solution. It can't be random noise, otherwise the chances are I'd be able to start the engine on the next attempt, and I'd be able to replicate it with the right jiggle of the virtual cockpit condition levers. OK. For now I have a workaround, so I'll just have to live with half a quadrant and just virtual cockpit those condition levers. Edit1: I found something My observation is that the propeller setting is always constant no matter what the condition lever position is. In the above instance engine 2 started fine, but engine 1 didn't. As you can see, engine 1 has a different propeller setting. Normally it needs to be 1395, but in this instance it isn't and it's stuck. I'll investigate some more, but I think I'm onto something. Edit 2: OK Everytime I load the aircraft, a successful engine start can always be predicted if the prop value is 1395.6. I've loaded up the aircraft 8 times, and three times the prop value for one engine has ended up being very low, and predictably the engine didn't start. So this is a problem that happens when the aircraft is loaded at the beginning. I'll investigate some more as to what causes these erroneous prop values. Edit 3: If I load the aircraft with prop levers away from the cut off position, then the chances are that either: Prop value is 1395.6 or Prop value is greater than 275 (start position, or higher) Basically the higher the condition lever position, the greater the initial prop value. A prop value of 275 or greater is sufficient to get the engines started. So the takeaway from this investigation is: make sure the aircraft is loaded with the condition levers not in the cutoff position, then you can get the aircraft engines started everytime. So Gregory: I suppose I was right and you were right. The only question for you is why are these prop values in a bistable fixed state either to 1395.6 or a value dependant on the condition lever once the aircraft has loaded? I would suggest as a solution: Fix the prop values to 1395.6 during startup or..... Make the prop value a dynamic variable with condition lever position. Either implementation will solve this problem without need for a workaround. Regards Anthony

It's not in the middle, It's actually after the end of a failed start once I've pulled the lever to cutoff before I try again without the hardware. But anyway.... Shouldn't engine start only consider the position of the condition levers - regardless of whether they are set by hardware, or by manipulation of the levers in the virtual cockpit? It shouldn't matter one bit whether hardware was disconnected during a flight session at all, except to freeze the existing position. I say "shouldn't", but obviously that isn't your thinking, and that difference between "shouldn't" and "doesn't" is something that only you can see. My understanding of the start logic is as such: - Condition Levers interlock the Start L/R switch from cranking the engine and charging the ignitors unless in the start position (not even a little bit outside the start position) - Start L/R will crank the engine and charge the ignitors once interlock is removed. - Condition Lever will introduce fuel into engine once cranking initiated for any lever position above the cutoff position. Fuel will subsequently ignite. Even with some noise in the condition levers, it would have to be considerable before fuel starvation becomes an issue. I simply haven't observed noise of such amplitude. My way of thinking about this logic is that it cannot correlate at all with the observations that I'm making, which suggests that the prop lever inputs from my throttle quadrant are triggering something quite erroneous in your code. No, I'll try tonight. I doubt it'll work however as there's no mention of this in the manual. If it does work, then the question then becomes where is this mentioned in the manual? There's only the cooldown interval that was discussed earlier, which as you say is bypassed with the use of the GPU.

If this remark about noise is correct, then whenever I have a failed ignition then I should be able to simply unplug the throttle quadrant and then restart the engine successfully. That will eliminate any such noise from the equation. Unfortunately this is not so. Once the engine has failed to ignite, it can't be successfully restarted until I have actually reloaded the aircraft. Furthermore, once the engine has started, I have to pull the condition lever back from the quite a distance before the engine is starved of fuel (literally just above the cutoff detent). The degree of lever movement for fuel starvation lies far outside any noise amplitude. In fact any throttle noise (and there is very little) is completely absorbed by the software detent for the start position. I still think there's some odd logic going on here. Sure enough, it's tied to the throttle quadrant being plugged in in the first place, but it lingers after the hardware has been unplugged.

OK. I think we're getting somewhere. Yes I'd say maybe 75% of the time the engines would start. But there was seemingly no rhyme or reason as to whether the engines started or not. It's purely a roll of the dice. I dialled down my procedure down to Batteries On, Condition Levers to Start and then Start L/R. I introduced no further steps and it was pure luck as to whether the engines started or not. Now your comment regarding hardware has got me thinking about my throttle quadrant, and about a particular paragraph in page 38 of the systems manual: So I wander if this logic is somehow tied into the condition lever. The condition lever will be brought into the start position, and then sometimes fall out a little bit due to my throttle quadrant having a physical detent that is just below the software detent for the start position. The result is a bit of jitter (which I bring under control prior to starting the engine). If every time it goes in and out of the start position that it triggers a cooling off period, that could explain it. I don't think the above logic shouldn be like this, as I'd have thought the cooling off logic should actually be tied to the Start switch. It makes no sense for the cooling interval logic to be tied to the condition lever start position. Afterall the battery is still being used to crank the engine and run the ignitors, and the cooling off period is used to protect the battery. But I wander if there's some odd logic here...…. Nothing else seems to explain the seeming randomness of the situation. I've had this problem in X-Plane 10, and now X-Plane 11 and the only common thread between the two simulators is my CH Throttle Quadrant. The plugins shared no commonality whatsoever. For now I've demapped my condition levers from the throttle quadrant, so I'll do some more testing tonight. Edit 1: More testing. I reloaded the aircraft, and rebooted the computer, and each time I had a successful start. I've done ten start attempts so far, so that's 20 engine starts and not one single start failure. So this is all done without the condition levers being mapped to the throttle quadrant. I'll now see if I can mimic a start failure based on my previous hunch. Edit 2: I tried to simulate the condition lever jumping in and out of the start position prior to start L/R. I couldn't replicate my hunch. I'm really at a loss as to why my throttle quadrant is giving me this grief. But at least I've managed to demonstrate a strong correlation between engine start failures, and condition levers being mapped to the CH Throttle Quadrant.

Just to be belt and braces about this. I updated my test copy of X-Plane and installed the LES into that copy. No other plugins installed. I reloaded the aircraft until I found an instance where the right engine didn't ignite. It cranked upto 40% RPM, but it didn't ignite, just like before. You can see in the picture above that the right engine is cranking, condition lever in start position, and "R IGN" light is annunciated. All the conditions for lighting the engine are there. I even made sure there was fuel in the tanks! Tried with manual and auto start procedures, exactly as described earlier. GizmoLog.txt Log.txt

Right. Plugins disabled, all except gizmo64. Reloaded the plane and the right engine fails to ignite. It's a manual start this time, but I'm sure it'll be the same result as the autostart. It'll crank the engine, but it doesn't ignite. Edit: Tried the autostart once the engines had stopped, and it fails on the right engine as expected. It cranks, but it does not ignite. I have only one idea what you mean by "hardware". If you're referring to my Brunner yoke, I disabled the plugin for that as well. Otherwise I'm not sure what you're meaning by "hardware". Log files attached again. Log.txt GizmoLog.txt

I know, but it is a problem, and it's probably the same root cause that affects both engine start methods. Since I was going to raise a post regardless, I thought I would tack my remarks on to this active topic. In fact I'm having problems again with manual start right now, so let's try the auto start procedure instead...… Gizmo Menu --> Auto Start --> Begin Autostart Steps 1-7 complete Step 8 Monitor Left Engine Start: In Progress. Observation: No engine cranking, Condition Levers Set to Cutoff. So lets sort that out. OK So condition Lever is now set to "start". Quite how step 5 (Move left condition lever to "Start") could compute a "complete" remark, when it's mapped to my throttle quadrant is something worthy of attention. OK. So it's stuck on Step 8. Let's hit the "X" in top right hand corner and try again. Attempt 2: Gizmo Menu --> Auto Start --> Begin AutoStart Steps 1-7 complete Step 8 Monitor Left Engine Start: In Progress. Observation: Engine cranking at 40% RPM, no ignition. Waiting for a minute ……. no change. Aborting Auto Start. So there you have it. The auto start failed on the same problem that I was having with the manual start. The engine was cranking, but it was not igniting. Log.txt GizmoLog.txt

I'll chime in here. I recently started using version 1.51 of this aircraft after a long period of inactivity (only just saved up enough money in FSEconomy to buy one!) If I go through the following basic sequence: - L & R Batteries ON - Ground Power Connected, external power ON - L, ESS and R Avion ON - COND Levers: START At this point I should be able to start my engines by moving the START switch to the L position for left engine or the R position for the right engine. Maybe 75% of the time the engines will crank, and ignite. However that 25% of the time, the engines will crank with eng RPM settling at 20%. There is no ignition. At this stage there is nothing I can do to get the engine started, except to reload the aircraft. I can abort the ignition, and try again to no avail. Not even a gizmo rebootbutton solves this problem. I've had this problem in X-Plane 10 with earlier versions of the aircraft, but it's carried through to X-Plane 11 in version 1.51 of this aircraft. I seem to remember earlier discussions on this topic suggesting that the authors of the aircraft couldn't reproduce this problem. I've attached log file for my current x-plane session. One additional remark, I notice that during engine ignition that it seems to ignite far too soon during the start sequence. The exhaust gas temperature gauge goes off the high end of the scale for a good 8+ seconds or so. I think that needs to be tweaked in the start sequence. Running X-Plane 11.41 Log.txt GizmoLog.txt

I just downloaded version 1.5 and last night I spend 90minutes trying to figure out why my engines weren't starting. Procedure used in summary: - Battery On - Ext Power connected, battery switched on - Throttle: Ground Idle - Props: Start - Start Lever: Left At this point my left engine should begin cranking, but that wasn't happening. This morning I had a eureka moment: I unplugged my CH throttle quadrant. repeated the above procedure and I get the engines started as expected. When I replugged the CH quadrant, the problem seems to be that the prop lever has to be **exactly** on the Start Detent - not *ever so* slightly above or below. This is actually very difficult because the CH-Quadrant has a physical detent that is located ever so slightly below the start detent. I retried with the Quadrant accounting for this, applying constant pressure to the levers to stop them falling into the physical detent. I could crank the engines, but once the essential busses were back online, the engines shutdown again. For now, the answer would be to not use the CH throttle quadrant.

This seems to be fixed for me in Beta 6. One of those glitches that's come and gone....

Hello Goram & Theo, I've been having an interesting ride during the x-plane beta testing phase. Some issues with the DC3 have come and gone. Now that Beta 6 is upon us, one issue looks likely to stick: 1. Load up the DC-3, cold and dark. 2. Notice the cooling fan sound. According to TKyler, in this post: http://forum.avsim.net/topic/381668-x-plane-1010-b6-released/#entry2437035 the avionics cooling fan 'bug' running on a dead bus "requires authors to go back and comply" I understand a further DC-3 revision is due, is this something that can be captured? Hopefully LR can fix the dancing engine gauges when engines are off. ----------------------- A couple of other things, not related to 10.10: 1. Gear down results in "landing gear unlocked" lighting up. This light is also active on a dead bus. I understand it should be green when landing gear is lockup up or down, and red when in transit. 2. Inner marker beacon lamp is (or appears to be) illiuminated on a dead bus. 3. Any chance of having click-drag manipulators for the radios and autopiliot knobs? They are quite hard to use with track IR. Barometer on altimeter is much nicer to use by comparison. Regards Anthony

Hello, One of the things in 10.10 that's been done by Laminar is to stop electric flaps operating on a dead bus. However on the CRJ the flaps were still working in the cold and dark state. So... I opened up planemaker and ticked the highlighted box So afterwards flaps don't operate on a dead bus (as should be the case)! Any chance you can catch this for the next update? --------------------- Hydraulics One of the things I've been investigating is to see how the hydraulics system hangs together. Test: 1. In flight, turn off hydraulic pumps 1, 3A & 3B. Leaving just pump 2 running. 2a. Operate landing gear - landing gear shouldn't move but it does. b. Roll the plane. Left aileron shouldn't move but it does. You can repeat the tests symetrically if you wish (and do more tests with brakes etc..), but the above test suggests that the hydraulic system only consists of one universal hydrailic circuit with 6 pumps, rather than three separate hydraulic circuits in x-plane. Is this a bug with the CRJ, or a limitation in x-plane that hasn't been highlighted? The hydraulics description in your manual isn't highlighted red, which suggests it should work as described. This isn't new for 10.10

Hello Goram Goran / Theo Don't mind if I jump in here? I've also discovered an autopilot related issue. I'm pretty sure this is related to the 10.10 Beta, and as such I've reported it on the LR bug report page. However I thought I'd bring it to your attention, since you might be able to engage with LR about it in more detail: ------------------------- In 10.10 B4 When I engage the autopilot, it maintains present attitude. However as soon as I adjust the pitch knob, the aircraft pitches up very steeply until the stall warning disconnects the autopilot. No matter what I try, I can't bring the pitch setpoint back down. When I try re-engage the autopilot the DC3 pitches up steeply straight away. This behaviour wasn't observed in 10.05r1. It worked as expected. ------------------------ On a side note, does the Sperry autopilot announce "Ding-a-ling-a-ling: Caution" when disconnected? Such a feature does sound a bit ahead of it's time for a 1940's autopilot !

Nice plane Goram & Theo! I'm not used to taildragger aircraft. I started off using the DC3 in 12kt crosswinds. That was a struggle to keep on the runway once landed. So I'm resetting my conditions now to calm weather. I'm quite happy landing the plane in calm conditions, and managed it without bouncing. However I find the brakes are very sensitive, with the tail wheel lifting up with even gentle braking application and if I'm not careful I end up faceplanting the plane. I'm using CH Pedals for braking. So I'm trying landings without braking at all, letting the aircraft coast down to taxi speeds. It 'feels' better controlled. Question is whether real DC3 pilots apply the brakes when landing to get down to taxi speed. Next lesson is crosswind landings. I'm not even trying free castoring yet.... too hard for now. Anthony p.s. the only posts I can see in this support forum are four pinned posts. Is this intentional?

Evening all, I've had two occasions now where both engines died on me mid flight. I've reasonably sure that the cause of failure was zero/negative G's. However the cause of that was plane getting too close to the red band on the speed display in altitude hold mode. The plane pitched up to bleed speed (as explained on the pinned topic) then the flight director commanded a pitch down and then the engines quit. Then I found I couldn't restart engines until around 10,000 feet. So there's some questions: 1. Can the flight director command a negative G maneuver, or is there something else at play here? 2. Shouldn't a pitch up command due to unsafe speeds be alerted, or is this as it is in real life? 3. How do I restart engines mid flight? I did the following: a. Startup the APU, open APU bleed valve and cross bleed b. ECS cabin packs off. c. Ignition on engine one, bring throttle from cut off to idle. (N2 speeds were around 27% anyway) d. Nothing happened, so I rebooted Gizmo - as that worked the first time round but nothing continued to happen. e. I carried out various combinations of the above in blind panic until around 10,000feet when I got the engines going again. 4. Are there any emergency procedures available to download for the CRJ? So I got back to cruising altitude to see what whether this pitching would happen again. It certainly did, but this time easing off the throttle near the red band -10 knots brought stability back to my flight.

Interesting. I haven't seen the selective deployment described in the manual anywhere (but it is mentioned in the tutorial that gentle landings will deploy). Just tried a few more landings, sometimes it deploys and sometimes not.

Thanks for the detail Philipp.

OK, I removed the reverse axis and configured the reverse toggle. Manual reverse thrust now works as you describe. However auto reverse thrust upon RTO or landing doesn't work anymore. Strange. Auto spoilers work fine on landing. Also, the reverse thrusters seem to bring the plane to a halt rather quickly on full blast (with mass of 39000lbs) - maybe using 400meters of ruwnway after touch down.. Is this how it is in real life?

Evening all, Try the following actions. 1.Start up the plane, "runway threshold" ready. 2. Enter the thrust limit page on the FMS. 3. Type 86 onto the scratchpad and enter it on the top left button (1LK). This shouldn't work according to the manual, but you should anyway observe strange happenings with your engines! On each occasion the engines shut down. Additionally: - Two occasions the ITT went crazy with the dial rotating anti-clockwise and showing minus thousands of degrees celcius. - Two other occasions the plane went backwards rather quickly. One resulting in a crash (a plane crash, not a CTD). It seems to be very repeatable. ---------------------------------------------------------- Now follow the manual (Page 73). Enter an outside air temperature into button 4RK. You'll observe the thrust limit numbers on the left all showing zero. For the purposes of this test I selected the TO number (1LK) to enter into the scratchpad before entering into 1RK. At this point the engines shutdown again with strange happenings.

I found this bug quite early on when going through the checklists. 1. Load up the CRJ in a cold and dark configuration (No Batteries and no AC Power) 2. Operate the flaps up and down. According to page 34 of the manual the flaps are connected to AC Bus 1 & 2 feeders, so I'd expect the flaps to be unavailable if the AC Busses are dead.

OK, I've just tried this out again, and here's some steps to reproduce : 1. Configure an axis input for reverse. 2. Load up the CRJ, getting into a flight ready state, take off and establish straight and level flight with some thrust. As per manual 3. Reduce throttles to idle, engage the reverse thrust with the reverse lever and observe reverse thrust engaged. 4. Place reverse lever back into normal position and confirm that throttle demands are available. Now here's the bug. 5. Place the throttle out of idle, and move the reverse thrust lever out of it's normal position. Observe the reverse thrust indicators flash on the engine instrument panel, only while the lever is being moved. Also observe that the normal engine thrust is being interrupted when the reverse thrust lever is being moved. 6. With the reverse thrust lever stationary, but in a reverse demand (not normal) position, confirm that the engines responds to normal throttle demands. 7. Place reverse thrust lever back into normal position. Here's another bug found 7. Perform steps 3 & 4 again, but this time observe how the throttles can't be operated once the reverse thrust lever has been put back to the normal position. 8. Nudge the reverse thrust levers forwards a little in the VC. Confirm that the throttles can respond to demand once more.

OK that makes sense. On the theme of reverse thrust. When I was in flight, I was able to (inadvertently) operate the reverse thrust levers (using the reverse axis), causing the reverse thrusters to kick in. According to the manual (page 23) this should only be possible if the throttle is in the idle state. They weren't idling. Never knew reverse thrust in flight was possible. I thought normally a weight on wheels interlock prevented this,. But I guess it sounds plausible for rear engined planes to have this feature.

Evening, Just bought the CRJ, and after a couple of nights of reading manuals and flying about I'm settling in nicely. Really nice plane with almost no extra toll on my framerates One thing I've noticed. On a couple of takeoffs with thrust reversers armed, they kicked in. This happened on what was admittedly a bumpy runway, when the wheels bounced off the runway and then hit the runway again, the thrust reversers kicked in. At first I thought that maybe having one of my CH Yoke levers configured for reverse thrust came off it's zero setting a little. Then I disabled the thrust reverser axis and tried again. Different bumpy runway, was just rotating to takeoff when my main undercarriage left the runway and greased the tarmac again. Reverse thrusters kicked in straight away. There was also one instance when lined up with the runway, I entered the thrust limit into the MCDU, but entered it into the wrong box (top left corner instead of top right), thrust reversers kicked in and dragged my plane backwards kicking and screaming for about 1/2 mile while I panicked at the scene unfolding! Is this supposed to happen? Anthony