Seekay
-
Posts
16 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Posts posted by Seekay
-
-
I truly do not understand why this is taking so long. This issue was first reported literally only a few days after the initial release. It has been nearly TWO YEARS and you still don't know what the hell is wrong with the plane? Not good, guys. Not good.
Like the poster above, this was my first Aerosoft product, but with the way you've handled (or should I say not handled?) the situation, it will likely be my last, and I will also strongly caution other people against buying it.
-
1
-
-
I agree. Aerosoft shouldn't be releasing new products when their existing products have issues that, in some cases, make them completely unusable. This is a 50€ addon and the fact that it still has major issues one year after release is unacceptable.
-
1
-
-
9 hours ago, Moach said:
I have done experiments and was able to isolate the exact nature and possible fix for the AP pitch up bug.
The issue goes as follows and can be easily reproduced even on the ground:
Problem: The internal variable used by the AP to track the pitch trim position does not update while AP is off.
Symptoms include:
- Engaging the autopilot in flight conditions where the pitch trim is set significantly far from neutral (such as, during late climb near cruise speeds) will cause an abrupt pitch up maneuver while the AP slowly tracks all the way down from it's last used trim position.
- On a first flight starting from the loading screen, this internal trim value will be 7.5, regardless of takeoff trim setting and pilot inputs while AP is kept off.
- If AP is engaged immediately after takeoff, this neutral state is near enough most T/O trim settings that the bump is very subtle and easy to miss.
- On subsequent non-restart flights, the AP engages with the last trim position it had at the time it was disconnected. As pilots are creatures of habit, that position most often matches the currently set real trim state, and the bump is also minimized.
- The issue can be easily reproduced while on the ground. Simply select a nose-down pitch setting on a freshly started flight, then engage the AP and observe the trim indicator. Notice how it will snap back to center immediately instead of tracking from the current position. (This snap-back is why the plane pitches hard up in the conditions mentioned above)
This should be simple to fix, having isolated the exact nature and manifestation of the problem.
Practical Solution: Ensure that whenever AP is engaged, the variable used to track pitch trim position is first copied from the actual state of trim on the aircraft. Alternatively, maintain a constant track of the trim state regardless of AP being on or off, so that when it's engaged, the internal AP state will match the selected trim position.
Even if the problem itself extends deeper somehow than a simple flawed initialization of the trim value, its practical effects are such that a symptomatic implementation of the solution above should almost certainly* suffice.
* Science-minded people will never say "definitely", even when they almost certainly* mean it.
Unfortunately, there is no viable workaround. The AP will always snap the trim to its last used state when engaged. Pilots can only take (unreasonable to impose) measures to prevent disruption of their flight path, either by engaging AP very early on takeoff while the trim is set near neutral, or by trying to cope with the bump during some part of the ascent where ATC won't mind the jerking.
This makes sense. I always wondered why the plane aggressively pitches down when I engage the autopilot and speed mode after takeoff. If I'm doing 160-180 knots in the early climb with the throttles at TOGA or CLB, I'll have a significant amount of nose up trim dialed in and the autopilot is just ignoring that and going back to neutral trim, causing the nose to drop.
-
7 hours ago, SinusJayCee said:
If you have speed mode enabled, speed bug set set to 290 and were actually flying at 290kt, you should have been exactly on the FD (at least regarding the attitude). But has the plane been trimmed for that attitude as well?
Yes, I was trimmed and hands off at 290 knots.
8 hours ago, TomAce said:If you use the original SimBrief profile for the CRJ, you will get the wrong ZFW. SimBrief set the passenger weight differently than the CRJ which again conflict with the EFB and FMS. SimBrief passenger weight includes bags, but the CRJ adds more weight in addition to the passenger weight and therefore the ZFW will be wrong.
If you set passenger weight in Simbrief profile to 186 pounds/ 84 kg it will be correct.
When I set this correct my plane stopped the odd behavior when turning AP on and I got correct ZFW in EFB.I use the EFB to set the overall ZFW of the plane (in ZFW mode, you simply enter the ZFW and the amount of fuel and it does the balancing), therefore the numbers given by Simbrief should still be valid as long as the ZFW is less than MZFW and TOW is less than MTOW, which they have been on every single one of my flights. And like I said, I've never seen the CG go out of bounds on the EFB's weight and balance chart.
Also, my takeoff trim is always within a few tenths of the center position (7.5) which indicates that the CG is correct; if it wasn't, I would need excessive amounts of trim to compensate for it.
-
18 hours ago, SinusJayCee said:
I get your point. But I also have to say that I never have seen such a severe behavior with a climb rate if 10,000ft/min. I usually get an increase to about 5,000ft/min, which is still not nice but less immersion breaking imho. For 10,000ft/min, the CG must have been totally out of range or your current attitude was far away from the FD.
I got my fuel and weights from Simbrief, the flight plan indicated that they were within limits, and I loaded the plane using the EFB's ZFW mode which (presumably) should set the CG correctly and notify me if there's a problem. I don't pay much attention to the CG indicator, I just trust the numbers Simbrief gives me, but I'm absolutely certain that I've never seen the indicator go beyond the takeoff, landing and approach CG limits.
I didn't check the attitude but I was climbing straight ahead with the HSI centered at 290 knots and had the autopilot speed bug set to 290 so I should've been right on the FD, no?
-
9 hours ago, SinusJayCee said:
this is no reason to quit the game by hitting Alt+F4
It is for me. It's so immersion breaking (even though it could technically happen in real life too) that I couldn't even be bothered to continue the flight.
-
This just happened to me for the first time today. I was trimmed at 290 knots with the HSI centered, enabled the speed and nav modes and engaged the autopilot at which point the plane started pitching up and reached a climb rate of over 10,000 ft/min before I alt-f4'd.
Soooo......any news?
in General Discussion
Posted
It really is disappointing. So much so that it almost makes PMDG look good in comparison because they at least engage with the community and regularly release detailed progress updates.
It would be hilarious if I hadn't spent money on this stupid plane. I actually bought it twice, first on the marketplace and then as a standalone package when that became available, because it looked promising and I trusted that there would be good support from the developer and any issues would be fixed reasonably quickly. But here we are, nearly three years later, still waiting for a fix to an issue that was discovered and reported pretty much immediately after release.
Seriously, what the hell is the matter with you guys? Why is it so damn difficult to just tell us what you've discovered and what fixes you've tried/are going to try? Many other developers do this (PMDG, Fenix, Simworks, FSReborn, Black Square, FlightFX, just to name a few off the top of my head) so why can't you?