I don’t know if you can do that in the real airplane either. I don’t think you can use waypoints created by you as departure airports. The only time I took off from an airport that wasn’t in the database we simply departed using conventional navigation using a nearby airport as origin and the FMC position got updated in the air as soon as it found a couple of good DMEs (It was a 757 that didn’t have GPS or RAAS).
Origin is optional, destination is required in the real plane (though it can be a custom airport - not a waypoint I don’t believe, but a custom created airport.). This picture shows the RTE1 page before being filled in (green text indicates probably a classic, but the logic works the same on the NG); note that Origin is just blank, but destination is blank boxes. Anytime you see these boxes in the FMC, they indicate a required entry. So you can see that only destination is required.
I believe that for the PMDG to work, you do need both origin and destination. Perhaps when they switch to the new navdata this will change?
Correct, in PMDG you have to fill the origin first, if origin is left empty and you try to fill the destination, you will only get ‘invalid entry’ message on the fmc. I guess I will have to stick to my not very clean workaround, but the autistic part of me does not like it very much 
Just align the IRSs properly and put in whatever nearby airport you can find. Fly conventional after departure. The airplane may complain when you push toga but it’ll update the FMC position later.
That is exactly what I do 
And if the destination airport is not in the nav database, I just use any nearby airport as a destination and add a custom waypoint with the real destination’s coordinates and do a standard VFR approach. I already did quite a few flights like that, never had any complaints from the aircraft somehow. Take off, hand fly for a while, then select the nearest waypoint as a ‘direct to’ in order to use vnav and lnav and it’s business as usual after that.
I guess in the real aircraft I would also have to monitor the pressurization system? Sometimes the elevation differences between ‘whatever nearby airport’ and the airport I actually use are quite big.
Yes but for destinations keep in mind that your EGPWS may give you wrong alerts in the modes related to unsafe terrain clearance (Too low terrain) when below 1000ft RA.
■■■■■■, you’re making me have to get out the books and look something up 
. I was going to say that the pressurization system doesn’t talk to the FMCs at all, pressurization schedule is just based on your cruise and destination elevations entered on the overhead panel. But then I realized, in an air return situation, the off sched descent mode will pressurize you back to departure airport elevation (unless you’ve already progressed a certain distance away from it.)
How does it do this? Does it get elevation from FMC database? Does it just take a snapshot of current elevation when toga is pressed? @FormerSnail5736 do you know?
Ah yes. The breathing part…
I’m super mixed up now because I’m in between types.
The AUTO system uses the cabin altitude reading when there’s weight on wheels before departure as departure elevation (Not from the FMC afaik). So if the airplane returns to land it’ll use the cabin altitude reading it had on the ground before departure as landing altitude and the OFF SCHED light will illuminate if you start descent before having entered cruise mode (±0.25psi to CRZ ALT). If you turn the LAND ALT knob to extinguish the OFF SCHED light you’ll lose that snapshot and will have to set it all the way to the correct LAND ALT. I don’t remember how long the 737 kept this snapshot. I know the 777 does it for the first 400nm or 50% trip (whichever earlier).
So basically if you’re returning to your original field there’s no need to change the LAND ALT if you return before 400nm or 50% of the route. If you’re returning to a different airfield you’ll have to manually set LAND ALT to the new airfield. In the 777 it does use information from the FMC to do this automatically but it can also be done manually (As you will all soon see).
Well so much for the avionics hangs being fixed. 2 flights into EHAM now and 2 x avionics hangs. First flight was v3.0.92 and 2nd was with v3.0.93. It’s so infuriating to lose all avionics on final. Yet officially it’s supposed to be ‘fixed’. 
It never used to do this back when it was first released.
I use the PMDG 738 almost exclusively and I’ve never experienced this issue, until yesterday. The only thing I did differently than usual was to reset the FSLTL traffic due to a plane going under me on final, and immediately afterwards the cockpit froze.
Interesting. Yes this happenes to me too. You get FSLTL IFR about to collide with you so you hit “remove nearby traffic” in the FSLTL toolbar and few minutes after the 737 avionics hangs. Not sure it’s the reason, but it could be. EHAM is always quite busy with IFR AI traffic. Sometimes I only zap them at 7000 ft though but the avionics hangs are always final/short final.
Today I zapped nearby traffic at approx 10 miles out, but avionics hung happened at maybe 3 miles out, so it’s not always an immediate effect if it is related.
737 is the same. I just couldn’t remember if it got altitude from the FMC but I didn’t think so either. 
This could be an interesting clue!
I’m currently doing the same flight again but with no FSLTL nearby traffic zaps this time to see if the problem goes away.
EDIT. Interestingly no hang despite heavy AI traffic. I may do a few more of these into EHAM to check this theory out. EHAM is definitely usually the place I have to resort to zapping FSLTL AI traffic the most.
OK, I’ve done 2 extra flights into EHAM this morning just to raise the probability of an avionics freeze, but without removing any nearby FSLTL AI traffic (while on the star or approach) and the good news is I’ve had ZERO avionics hangs on final.
Ordinarily I’d have had one by now, that’s 3 straight flights now with no hangs. This looks promising. Apparently we just have to let the crazy AI do it’s thing even if it lands on top of us.
Perhaps it’s the simconnect AI removal commands that could be messing with the 737 TCAS system causing the avionics hangs. Thank your for your help in diagnosing this.
In fact I can confirm that I have never reset the FSLTL traffic and I have never had a freeze. The only time I reset it this happened. I also did other test flights without touching traffic anymore and I didn’t have any problems. Hopefully this can help others too.
This is useful info. I think for me EHAM and AI traffic is a worst case scenario, as aircraft are all/nearly all sent to waypoint SPL (directly overhead of EHAM) at 7000ft before turning onto their designated approach. It’s also a very busy hub, so you get a lot of AI converging at SPL at times causing TCAS proximity encounters.
So if anyone wants to maximise their chances of recreating this issue then EHAM via SPL waypoint at 7000ft with FSLTL enabled (I run with IFR 50) then go “clear nearby AI traffic” in FSLTL when they get too close around SPL or on the approach/final. It seems that this nearly always results in an 737 avionics freezes on final approach. My traffic radar and TCAS/TA/RA are both also on during this whole time.
Will need to confirm the freeze again by trying to do just that, but it is definitely something for the devs to go figure out.
Will the PMDG developers implement the weather radar now that Active Sky FS has been released with its new API? I remember that in Prepar3D the PMDG and FSLabs weather radars only worked with Active Sky. I think it’s time to implement it. What do you think?
Thanks for the link. I’ll just make sure that I grab some popcorn before going to read a discussion about that topic over there 