Merlin negative G cutout too quick?

[klem]

Originally Posted by 41Sqn_Stormcrow

Actually I remember the discussion on the cut off behaviour in its release state very well. In fact the devs never said that the g levels were wrong but they understood that the way it was implemented led to some oversensitivity. BTW back then the concern was merely that turbulences were enough to cause the first stage of cut out. So the devs eliminated basically the first stage of cut out completely while it actually should have been there. To my feeling (as you put forward your feelings I may too) they just should have removed the instant first stage cut out due to turbulences by putting in some inertial behaviour of the first stage cut out to render it more insensitive to small to medium turbulences.

I also do thing that the current cut out is not over sensitive.

BTW I do not understand what you expect them to do. You want them to check the g level from which cut out occurs. So you want to know the number and that's it? Or do you want them to make it less sensitive whatever g number they have used? If the latter is the case please provide some historic documents that supports your view that g level has to be improved.

First I don't think light turbulence would cause cutout - and that was confirmed to me by a current MkI Merlin III Hurricane display pilot - but in the release version it blipped continuously in level flight. Second, the documented data is in the Tracker, 0.1G cutout according to the Royal Aircraft Establishment who tested for it in the aircraft in 1940. Third there are a number of reasonable estimates of what the delay might be to cut and recovery including the opinion I posted way back from the Hurricane display pilot I mentioned plus buried away somewhere some documents giving an opinion at the time.

What do I expect them to do? What they said when they committed to as accurate modelling of FMs as possible by checking whether the documented data is incorporated into the flight model or if the FM is still using an estimated value for the last patch. Its that simple and I don't understand why anyone would want to say "No! Don't check it!" What is there to be afraid of? Either its correct or it isn't.

No amount of discussion here will answer this, only they know.

[trademe900]

Why do I get no engine cut out at all? Some setting that I have somehow missed?

[von Brühl]

Originally Posted by trademe900

Why do I get no engine cut out at all? Some setting that I have somehow missed?

Make sure all relevant engine settings (CEM especially) are on.

[41Sqn_Banks]

IIRC in the release version cut-out was at 0.5 G and was reduced to 0.1 G with a patch. Luthier stated these values.

There is way to much "feeling" in bugtracker issue. I think it should be possible to get the G force using a mission script to verify the values. It's possible to log the position (x, y, z), speed and the time, should be enough to calculate the G forces, shouldn't it?

Someone should collect the reference material to find out at which value the engine should cut. Someone else should test the implementation by doing flight test and calculate the G force.

Then we have something to compare and don't need to talk about feelings and opinions.

[CWMV]

Thought I saw it posted somewhere around here that it was documented to happen at .9G?

[klem]

Originally Posted by 41Sqn_Banks

IIRC in the release version cut-out was at 0.5 G and was reduced to 0.1 G with a patch. Luthier stated these values.

There is way to much "feeling" in bugtracker issue. I think it should be possible to get the G force using a mission script to verify the values. It's possible to log the position (x, y, z), speed and the time, should be enough to calculate the G forces, shouldn't it?

Someone should collect the reference material to find out at which value the engine should cut. Someone else should test the implementation by doing flight test and calculate the G force.

Then we have something to compare and don't need to talk about feelings and opinions.

"Someone should collect the reference material to find out at which value the engine should cut."

That data is given (linked) in the original Tracker request.

"Someone else should test the implementation by doing flight test and calculate the G force."

That is precisely what the Bug Tracker entry asks the devs to do.

I don't want to offend you but did you read the Bug Tracker entry and Description?

Originally Posted by 41Sqn_Banks

There is way to much "feeling" in bugtracker issue. I think it should be possible to get the G force using a mission script to verify the values. It's possible to log the position (x, y, z), speed and the time, should be enough to calculate the G forces, shouldn't it?

Someone should collect the reference material to find out at which value the engine should cut. Someone else should test the implementation by doing flight test and calculate the G force.

Then we have something to compare and don't need to talk about feelings and opinions.

THANK you, Banks

[bolox]

there's this parameter
[Misc.: Machine Overload under Acceleration]
/// <para>Indicates overload in m/s/s.</para>
/// <para>Generic subtype (-1) shows accelerometer, being 0 under normal conditions;</para>
/// <para>Subtype 0 shows acceleraton along machine's X axis;</para>
/// <para>Subtype 1 shows acceleraton along machine's Y axis;</para>
/// <para>Subtype 2 shows acceleraton along machine's Z axis.</para>

if doing the test from level flight Z axis should work ok- i've got it reading to a 'speedbar' atm but only in integers (that's all i needed )

[TomcatViP]

Originally Posted by CWMV

Thought I saw it posted somewhere around here that it was documented to happen at .9G?

Yes it is.

[WTE_Galway]

Am I missing something here (I haven't bothered reading the whole thread everyone in here is too cantankerous) or are people expecting the Merlin flooding problem to turn on and off at a particular G setting like a switch ?

As far as i recall the flooding was not instant and neither was the recovery, anecdotally the flooded Merlin engines would eventually clear and self restart if still spinning, but certainly not instantly.