Jump to content
Sign in to follow this  
fabristunt

747 V3 crash when using PBD

Recommended Posts

I had a crash while enroute over the Atlantic. I wanted to insert a PBD waypoint, starting from one of the coordinates I was going to fly to. Downselected it, added the bearing and the distance and right when I tried to insert it in the LEGS page, P3D crashed. I wasn't able to reproduce this issue when trying again at parking, but I'm afraid it will happen again. Did any of you encounter this problem?

 

qotsii%20crash2_zpsqr7sgug3.jpg

 

qotsii%20crash_zpsxh5kx9ea.jpg

 

Regards,

Fabrizio


Fabrizio Barbierato

CLX319_zps10aeywtl.pngECN0550.png

Share this post


Link to post
Share on other sites

Nope..., but be glad to try.  Please provide exact steps to reproduce the event.


Dan Downs KCRP

Share this post


Link to post
Share on other sites

Hi Dan, thanks for your reply.

 

(FPL-GTI8148-IS
-B744/H-SDE3FGHIM1M2RWXY/LB1
-KJFK1410
-N0480F310 BETTE DCT ACK DCT BRADD N141D PORTI/M084F330 DCT
47N050W DCT 50N040W DCT 52N030W DCT 53N020W DCT MALOT/N0489F330 DCT
GISTI/N0482F350 DCT KER DCT EVRIN UL607 SPI UT180 PESOV T180 UNOKO
-EDDF0627 ELLX
-PBN/A1B1C1D1L1O1 DOF/170205 REG/N475MC EET/KZBW0003 CZQM0045
CZQX0137 47N050W0209 50N040W0257 EGGX0339 53N020W0417 EISN0435
EGTT0509 EBUR0546 EDGG0609 SEL/RSJM OPR/GTI RALT/LPLA EIDW RMK/TCAS)
 
When inbound 50N040W downselect 52N030W from the legs page and add 266/50 as PBD. Then insert it before 52N030W. Right when clicking the LSK I got the crash.

Fabrizio Barbierato

CLX319_zps10aeywtl.pngECN0550.png

Share this post


Link to post
Share on other sites

Funny enough, the 777's I fly with have a bullitin that states not to put PBD's as active waypoints on a secondary flight plan

as it might reset the FMC...... Funny..


Xander Koote

All round aviation geek

1st Officer Boeing 777

Share this post


Link to post
Share on other sites

 

Hi Dan, thanks for your reply.

 

(FPL-GTI8148-IS
-B744/H-SDE3FGHIM1M2RWXY/LB1
-KJFK1410
-N0480F310 BETTE DCT ACK DCT BRADD N141D PORTI/M084F330 DCT
47N050W DCT 50N040W DCT 52N030W DCT 53N020W DCT MALOT/N0489F330 DCT
GISTI/N0482F350 DCT KER DCT EVRIN UL607 SPI UT180 PESOV T180 UNOKO
-EDDF0627 ELLX
-PBN/A1B1C1D1L1O1 DOF/170205 REG/N475MC EET/KZBW0003 CZQM0045
CZQX0137 47N050W0209 50N040W0257 EGGX0339 53N020W0417 EISN0435
EGTT0509 EBUR0546 EDGG0609 SEL/RSJM OPR/GTI RALT/LPLA EIDW RMK/TCAS)
 
When inbound 50N040W downselect 52N030W from the legs page and add 266/50 as PBD. Then insert it before 52N030W. Right when clicking the LSK I got the crash.

 

That's good.  Please go to PMDG Product Support, create a support account if you do not have one and open a trouble ticket with exactly this info.  It will be looked at by PMDG and probably end up in the bug tracking system. Thanks for finding this.

 

Even if the PDB waypoint is an invalid input it should not cause a crash.


Dan Downs KCRP

Share this post


Link to post
Share on other sites

I use pbd off of lat/lon wpt's and have never had an issue, but it sounds like you can replicate so you should create a ticket for it.

 

I'm not game to try on my current flight (10hrs elapsed, 3hrs to go).


Brian Nellis

Share this post


Link to post
Share on other sites

Thanks for your replies. I'll try a couple times to recreate it. If it still happens, I'll file the support ticket.

 

Edit:

 

Hang on, I may be onto something. It may have to do with importing a flight plan created with Simbrief.com

Maybe it's compiled in a wrong way or something.


Fabrizio Barbierato

CLX319_zps10aeywtl.pngECN0550.png

Share this post


Link to post
Share on other sites

Bingo. I found it. TL, DR version down below.

 

The problem isn't simbrief, not completely at least. Bear with me for a few more minutes. 

 

Wanting to know more, I tried some stuff.

 

What follows can be recreated every time. It is not necessary to actually fly, I was at the Cargo ramp in the 747-400F just on APU, definitely not inflight.

 

 

1) Thinking it was simbrief, I tried to type the fpl in the fmc by myself. As it's 0048 Local time here, to speed things up a bit I used the ARINC shorthand format (Have a look here:http://code7700.com/arinc_424_shorthand.html)

After entering the FPL, I tried to add a PBD. When I downselect 5230N from the legs page, the FMC puts 5230N in the scratchpad. . 

Adding 268/50 makes it become 5230N268/50. Adding it to the legs page creates the costum waypoint I wanted to enter and adds a Discontinuity before that. All good so far.

 

2) Happy with the result, I suspected the datalink fpl importing function. I saved the fpl created in 1), cancelled what I had in my FMC and imported the freshly created fpl. The same thing I had in No 1 is what happens. It works.

 

3) I tried again with simbrief, redownloading the FPL. Still the exact same thing as in the first two tests. When typing the fpl in Simbrief.com I was still using the ARINC Shorthand format for my coordinates.

 

4) I then noticed that the fpl created with simbrief for the flight that made my Queen crash didn't use the ARINC Shorthand format. That's because when typing the fpl in simbrief for that flight, I didn't use the shorthand format. I used N52W030 and so on. And here it becomes interesting. When importing a fpl created using the long ARINC format*, the legs page shows N52W030. When downselecting that in the legs page, the scratchpad returns N52W030, adding the 268/50 PDB data makes it N52W03026/50. When I try to add that in the legs page, it instantly crashes. You can in the first post that it's really the Queen's dll that causes P3D to crash.

 

* It may not be the actual name of it, but let's call it like that for now.

 

5) Still not happy with that, I tried to create a fpl using the format I used on that flight, N52W030.

Here's that big thing. When downselecting N52W030 from the legs page, the scratchpad doesn't show N52W030, but instead I get it in decimal degrees! N5300.0W02000.0 If I now try to add the PBD, I get N5300.0W02000.0268/50. Adding it to the legs page gives me a NOT IN DATABASE error, probably due to the length of that, but doesn't affect the 747 in any other way. It doesnt crash!

 

6) Happy with the success, but still eager to know more, I went on to dig some more. I saved the fpl created by my using the long ARINC format and then imported it via datalink. Again, downselecting N52W030 from the legs page, the scratchpad doesn't show N52W030, but N5300.0W02000.0 as in test No 5. I also get the NOT IN DATABASE error, as this format isn't accepted by the FMC.

 

It means something's wrong in the FPL coded by Simbrief.

 

Simbrief's .rte file using the ARINC Shorthand

 

5230N
5
DIRECT
1 N 52 W 30 0
0
0
0
 
5320N
5
DIRECT
1 N 53 W 20 0
0
0
0

 

 

 
Simbrief's .rte file using the long ARINC format
 
 
N52W030
5
DIRECT
1 N 52 W 30 0
0
0
0
 
N53W020
5
DIRECT
1 N 53 W 20 0
0
0
0

 

 

PMDG's .rte file using the  ARINC Shorthand

 

 
 
5230N
5230N
-
2
1
0
DIRECT
1 N 52 W 30 0 
0
0
0
X
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0 0 0
4
0 -1000000 0 0
0 -1000000 0 0
0 -1000000 0 0
0 -1000000 0 0
-1000000 999 0
 
5320N
5320N
-
2
1
0
DIRECT
1 N 53 W 20 0 
0
0
0
X
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0 0 0
4
0 -1000000 0 0
0 -1000000 0 0
0 -1000000 0 0
0 -1000000 0 0
-1000000 999 0

 

 

 
 
PMDG's .rte file using the long ARINC format
 
 
N52W030
N52W030
N5200.0W03060.0
2
6
0
DIRECT
1 N 52 W 30 0 
0
0
0
X
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0 0 0
4
0 -1000000 0 0
0 -1000000 0 0
0 -1000000 0 0
0 -1000000 0 0
-1000000 999 0
 
N53W020
N53W020
N5300.0W02000.0
2
6
0
DIRECT
1 N 53 W 20 0 
0
0
0
X
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0 0 0
4
0 -1000000 0 0
0 -1000000 0 0
0 -1000000 0 0
0 -1000000 0 0
-1000000 999 0

 

 

Simbrief is using way less zeros. I don't know what they mean, it's likely to be found in the SDK but I'm really tired now. Anyway, I don't think that they are the problem, as using Simbrief's fpl with ARINC shorthand works just fine and that doesn't have the zeros in it.
 
Besides the zeros, the other difference I see is this:
 
Simbrief Long ARINC .rte
 
N53W020
5
DIRECT
1 N 53 W 20 0

 

 

PMDG's Long ARINC ,rte

 

N53W020
N53W020
N5300.0W02000.0
2
6
0
DIRECT
1 N 53 W 20 0 

 

 

The PMDG Long ARINC format is adding the waypoint in decimal degrees (N5300.0W02000.0) and also repeating N53W020 twice at the beginning. The repetition may not be the problem, as Simbrief's fpl created with the ARINC shorthand doesn't repeat it either, but still works. The third line is the problem: N5300.0W02000.0 Simbrief's fpl with the longer ARINC format doesn't add that. I guess that there are three lines in there for something like " the 1st is what the user puts in, the second is that the FMC shows, the third is what the FMC uses if the format used in the second line is not supported.
 
Too Long, Didn't Read version:  do not try to add a Place Bearing distance to a fix made of coordinates using the long format (N52W030) if using an .rte file created with Simbrief or you'll get a flight sim crash.
 
Temporary workaround: Use the ARINC shorthand (5230N) when inserting your fpl on Simbrief. 
 
Either that, or use it when adding a PBD on your fmc. Downselecting the long format on a PMDG created .rte file gives you the decimal degrees, but you can't add a PDB to them (which I suppose is right, I'll look into the documentation tomorrow).  Downselecting the long format and trying to add a PBD to it on a .rte file created with Simbrief gives you a flight sim crash.
 
Tomorrow I'll write on Simbrief's forum too, so they can look into it, but it would be nice if the Queen didn't crash when getting the wrong format. Shouldn't I get NOT IN DATABASE as in test No 5 and 6 higher up in this post?
 
That being said, I'm off to bed.
01:53 AM here, near Milan.
 
Regards,
Fabrizio

Fabrizio Barbierato

CLX319_zps10aeywtl.pngECN0550.png

Share this post


Link to post
Share on other sites

Should it matter something, I want to point out that, in all the tests I made, the PDB wasn't being added to be the active waypoint, there was a part of route before it.

 

Also, I opened a support ticket as Dan and Brian suggested.

 

Regards,

Fabrizio


Fabrizio Barbierato

CLX319_zps10aeywtl.pngECN0550.png

Share this post


Link to post
Share on other sites

Ciao Fabrizio,

 

Had a look at it from a ticket forwarded from support. It is a SimBrief issue saving a custom AIRAC object with a name too long against PMDG flughtplan specs. Added protection against that so please wait for the next update.

 

Grazie,

 

Vangelis


====================================

E M V

Precision Manuals Development Group

====================================

Share this post


Link to post
Share on other sites

Yassou Vangelis, 

Thanks for looking into it.

 

I'll write on the Simbrief forum so they can look into it as well.

 

In the meantime,

 

 

 


Temporary workaround: Use the ARINC shorthand (5230N) when inserting your fpl on Simbrief. 

 

Regards,

Fabrizio


Fabrizio Barbierato

CLX319_zps10aeywtl.pngECN0550.png

Share this post


Link to post
Share on other sites

Atta boy Fabrizio, you got a thanks from Dr Ev(il) himself :)

  • Upvote 1

Dan Downs KCRP

Share this post


Link to post
Share on other sites

For SimBrief's part, this has been fixed by simply converting to the ARINC424 shorthand when outputting PMDG route files. I'm hesitant to add the extra fields present in the 747 native routes referenced above as I don't want to cause any compatibility issues with older PMDG products.

 

Is there any detailed documentation available for the PMDG .rte format? It would be nice to better understand the fields and avoid any potential problems like this in the future.

 

Thanks,

 

 - Derek Mayer

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Tom Allensworth,
    Founder of AVSIM Online


  • Flight Simulation's Premier Resource!

    AVSIM is a free service to the flight simulation community. AVSIM is staffed completely by volunteers and all funds donated to AVSIM go directly back to supporting the community. Your donation here helps to pay our bandwidth costs, emergency funding, and other general costs that crop up from time to time. Thank you for your support!

    Click here for more information and to see all donations year to date.
×
×
  • Create New...