58 minutes ago, BWBriscoe said:

How do I get the correct CG?

try INIT --> INDEX --> SETTINGS --> WEIGHT&BALANCE --> SET FROM OFP

 

this is how I did it (so far), hope that is correct 😉 

EDIT: And yes, this is for Simbrief. YMMV especially if you do not import from simbrief

Edited October 28, 20232 yr by DAD

1 hour ago, Treetops45 said:

What would you recommend if you don't use Simbrief?

I tried one scenario without Simbrief and the results were as explained by many here a borked take-off. This is the key, the weights have to be imported from the OFP (Simbrief). The calculations are entirely different, here is one example:

I took the NTAA-KLAX flight as described by anniran above with exactly the same weights, I did not use the Weight & Balance page of the FMC but the MSFS weight page, all my results were wrong and I could not take-off at the calculated VR. Here are the comparisons:

Anniran:  486'000 lbs TOW, 141000 lbs fuel CG 11% trim 8.5, with MSFS weight page, I obtained the same results and a RTO

My Simbrief: Same weights, CG 19%, trim 6.75, V1 149, VR 152, V2 160 Keep in mind I used the EFB calculation for the take-off performance as should be the case. I could rotate at 152 with a 7° nose-up, no tail strike, no difficulty.

So there is clearly a difference between the two input and Simbrief is the way forward IF one also includes all the Weight & Balance page input and EFB calculations.

Edited October 28, 20232 yr by Bernard Ducret

19 hours ago, Jure said:

Same here, far from being heavy, light on fuel. The plane lifted close to 190 kts and I actually had a tail strike. Something is not right. Trim was set up correctly, by the way.

How does anything get released like this?

14 hours ago, btacon said:

Wanna bet?  Do you have anything of value to add to this discussion or will we just play “tit for tat”.  You would do well to show gratitude for the Graceful acts of others (Horizon Simulation).  Or if you have no appreciation to show, better to just sit still and hold your tounge. 
-B

I don't think people are generally ungrateful.  But after months and months of hype and a very good visual model, people just get knacked off when reasonable expectations become disappointments

18 minutes ago, ErichB said:

people just get knacked off when reasonable expectations become disappointments

They shouldn't.

This is a team working on a free product with limited development and testing resources on their own time, who very obviously and in good faith thought they had a problem solved. The community should be patting these folks on the back for their incredible work thus far and doing whatever they can to help the team solve the (clearly unexpected) problem.

It is not actually reasonable to expect a team of this size and time commitment to be able to catch every bug, and despite what people think, it very much happens all the time in testing that a bug that affects even a huge percent of users may absolutely never have been seen by a couple of devs and testers, even in the same conditions. The assumption of "well it's glaring to me so it should have been glaring to the team" simply doesn't hold in software development, as much as every developer and QA tester on the planet wishes it did.

I've lost count of the number of times we released something (especially in the mod days) with some whopper that nearly affected everyone, leaving us all scratching our heads going, "we did that exact same thing (quite literally) a thousand times, why didn't this happen for us?" It's just the nature of the beast, but also one of the shining strengths: when you're able to come together with the community as a team and solve a problem, it's really just an incredible thing.

I for one am massively impressed in the 78 mod teams so far, working without source code in the relative dark and still managing to pull out wins in extraordinarily short timescales. It warms my heart and is one of the big reasons we joined the MSFS team, to enable this kind of magic. It's truly thrilling and humbling to watch.

16 minutes ago, MattNischan said:

They shouldn't.

This is a team working on a free product with limited development and testing resources on their own time, who very obviously and in good faith thought they had a problem solved. The community should be patting these folks on the back for their incredible work thus far and doing whatever they can to help the team solve the (clearly unexpected) problem.

It is not actually reasonable to expect a team of this size and time commitment to be able to catch every bug, and despite what people think, it very much happens all the time in testing that a bug that affects even a huge percent of users may absolutely never have been seen by a couple of devs and testers, even in the same conditions. The assumption of "well it's glaring to me so it should have been glaring to the team" simply doesn't hold in software development, as much as every developer and QA tester on the planet wishes it did.

I've lost count of the number of times we released something (especially in the mod days) with some whopper that nearly affected everyone, leaving us all scratching our heads going, "we did that exact same thing (quite literally) a thousand times, why didn't this happen for us?" It's just the nature of the beast, but also one of the shining strengths: when you're able to come together with the community as a team and solve a problem, it's really just an incredible thing.

I for one am massively impressed in the 78 mod teams so far, working without source code in the relative dark and still managing to pull out wins in extraordinarily short timescales. It warms my heart and is one of the big reasons we joined the MSFS team, to enable this kind of magic. It's truly thrilling and humbling to watch.

Well said and absolutly true words !! 👍

There seems not much respect anymore around, such teams doeing that hard work and pushing it for the using community out -  and guys that's a shame..🤔

 

cheers 😉

Edited October 28, 20232 yr by pmplayer

Can someone confirm if the problem exists using simbrief in the correct manner?

It's very conflicting in here; some people have no issues and others are doing the usual crying. There's an official post on their Discord and Bernard is saying there isn't an issue. 🤕

Edited October 28, 20232 yr by El Diablito

18 minutes ago, El Diablito said:

Can someone confirm if the problem exists using simbrief in the correct manner?

🤕

I do not have any problems with takeoff and takeoff speeds. All data is loaded in using simbrief. I even simulate Scoot capacity and put 360 pax. Simbrief calculates all weights correctly. For short flights I have a high payload but low fuel. So my CG is always around 29-30% and trim is 2.75 - 3.25. Vr is around 147 and flaps 5.  Plus a huge engines derate. All data calculated using EFB. I have no problem with rotation at 147 and flaps 5.

Not many of us did the full flight I guess. So expect another surprise. On short final when I turn autopilot off plane suddenly gets a high pitch up. To correct this I pull down yoke and get sinkrate and hard landing.🤷🏻‍♂️

I imported everything using simbrief and did TO calculations using EFB. It gave me a CG of 27% and a trim of 4.25 (which I thought was a very nose down trim). 

At Vr, I started to rotate the nose, needed quite a bit of pressure on the yoke (thrustmaster 787 yoke), but the nose did lift. However I did suffer a tail strike. 

In my limited flights I definitely didn’t experience the late take off/tail strike, but as with my previous post - this is how I load my plane

1) simbrief import it all the weights/fuel in via FMC

2) go to MSFS W/B page, don’t touch any of the weights, just click on the CG slider (you may need to expand the W/B window wider, the CG is on the right side), even if just move the dot to the same place it again from where it has been, the CG will be in a more reasonable value and the TO trim will be also more reasonable.

Good luck!

2 hours ago, Bernard Ducret said:

I tried one scenario without Simbrief and the results were as explained by many here a borked take-off. This is the key, the weights have to be imported from the OFP (Simbrief). The calculations are entirely different, here is one example:

I took the NTAA-KLAX flight as described by anniran above with exactly the same weights, I did not use the Weight & Balance

So there is clearly a difference between the two input and Simbrief is the way forward IF one also includes all the Weight & Balance page input and EFB calculations.

Thanks for your input.

Where does one find the Simbrief download section in the FMC? (Menu tree?)

T45

20 minutes ago, Treetops45 said:

Where does one find the Simbrief download section in the FMC? 

For the Weight & Balance you will find it in the Settings page (to have access to that page, click on INDEX on LSK 6), you will first need to ensure you are logged in Simbrief, if you have to do that, click on Next Page, input your Simbrief ID and revert to Previous Page, then click on Weight & Balance (RSK6), on that page, click on SET FROM OFP (LSK5 if I remember correctly), your data will be imported into the FMC automatically, that's it. 

I need to point out a few more important details, don't forget to import the Horizon B789 Simbrief two profiles (RR and GENx) into your Simbrief (otherwise your calculations will be very approximate) do not use the Simbrief default B789 profile. 

Remember to input the wind and temperature at your departure airport on the second page of the Take-off REF, they will be needed by the EFB for your final performance calculations. No need to extract the CG from the MSFS Weight page, simply click on the key facing CG (LSK3?) on the Take-off page, it will be automatically populated, as a rule, never use the Weight MSFS menu this will lead to wrong calculations.

Lastly, when using the EFB Performance calculations, make sure to select the RWY condition, RTG Optimum, Flaps 5 (or 10 if needed), A/I Engine Auto, press Calculate, and Send to FMC, Accept in FMC and you're ready to go.

I hope this helps 

1 hour ago, silentghostx said:

go to MSFS W/B page, don’t touch any of the weights, just click on the CG slider (you may need to expand the W/B window wider, the CG is on the right side), even if just move the dot to the same place it again from where it has been, the CG will be in a more reasonable value and the TO trim will be also more reasonable.

 

Don't touch any value in that MSFS Weight window and don't even open it. Your CG will be given by your FMC on the Take-off page, click on the LSK next to it and it will be populated, then your TO trim will be indicated automatically there as well, no need to use MSFS menu.

2 hours ago, El Diablito said:

Can someone confirm if the problem exists using simbrief in the correct manner?

It's very conflicting in here; some people have no issues and others are doing the usual crying. There's an official post on their Discord and Bernard is saying there isn't an issue.

There is no calculation issue if one adhere strictly to the procedure, but if any of the normal steps is/are ignored, bypassed, then there will almost surely be an issue. Starting with making sure one uses the two Horizon B789 RR and GENx Simbrief profiles as indicated in my post above (the B789 Simbrief default profile is not really accurate for these two simulations). Then each phase Importing Simbrief Weight & Balance in the FMC, inputing the weather parameters in page 2 of the Take-off and using the EFB for the final calculations are all essential.

At least all your calculations (in particular CG and TO trim, V1, VR, V2 speeds) will be correct and you won't find yourself speeding beyond VR on your TO run, however the challenge will remain to rotate without a tail strike, as indicated by the developer, one has to be moderate (avoid exceeding 7/8°), this is dependent on your yoke hardware and its sensitivity settings.

Edited October 28, 20232 yr by Bernard Ducret

2 hours ago, Bernard Ducret said:

At least all your calculations (in particular CG and TO trim, V1, VR, V2 speeds) will be correct and you won't find yourself speeding beyond VR on your TO run, however the challenge will remain to rotate without a tail strike, as indicated by the developer, one has to be moderate (avoid exceeding 7/8°), this is dependent on your yoke hardware and its sensitivity settings.

I agree completely. I too have found, and it’s repeatable, if you follow the exact steps Bernard described you will get realistic CGs, VR speeds and climb outs.  I saw on the HS Discord that they were recommending 15 degrees flaps at takeoff.  I’ve been doing just that and I’ve had very satisfactory departures and flights. 

YMMV  TANSTAAFL

-B