FSDreamTeam forum
Products Support => GSX Support MSFS => Topic started by: jack153 on August 25, 2022, 08:42:51 pm
-
i have the 737-800 loaded with 184 seats but 214 how is that possible?
-
Me too. Had 184 on Simbrief, but 214 in GSX.
-
Please check ALL the conditions using Simbrief have been satisfied, Page 60 of the manual.
If you want to check what GSX is doing, just turn on logging, and activate a gate, there's a lot of diagnostic about SimBrief, telling all the possible reasons why your flight plan hasn't been used.
One thing that can be easily overlook is the airplane ICAO type, if you use the default profile for a 737-800 on Simbrief, the airplane code is B738, which is the official ICAO type for the airplane. However, PMDG has set the icao_model in the aircraft.cfg as "737-800", GSX obviously read the icao code from SimBrief *and* the icao code from the airplane, so it expects them to match, otherwise it would think the airplane it's not the correct type.
Unfortunately, the ICAO code in Simbrief airplane editor only accepts 4 characters, so I guess your best option would be editing the aircraft.cfg to read B738, or ask (gently) to PMDG if they would be willing to use the standard ICAO type in the icao_code field of the aircraft.cfg.
-
It looks like the PMDG 737-800 has the incorrect ICAO code listed in the aircraft.cfg- they have it as B737 and 737-700
Correct the entries so they look like this:
[General]
atc_type="BOEING"
atc_model="B737"
Category = "airplane"
icao_type_designator="B738"
icao_manufacturer="Boeing"
icao_model="737-800"
-
THANK YOU! This has been driving me crazy as well on 738.
-
It looks like the PMDG 737-800 has the incorrect ICAO code listed in the aircraft.cfg- they have it as B737 and 737-700
Correct the entries so they look like this:
[General]
atc_type="BOEING"
atc_model="B737"
Category = "airplane"
icao_type_designator="B738"
icao_manufacturer="Boeing"
icao_model="737-800"
where should the path to this be?
-
icao_model should be "B738", that's the official ICAO code which is also what Simbrief use.
-
It looks like the PMDG 737-800 has the incorrect ICAO code listed in the aircraft.cfg- they have it as B737 and 737-700
Correct the entries so they look like this:
[General]
atc_type="BOEING"
atc_model="B737"
Category = "airplane"
icao_type_designator="B738"
icao_manufacturer="Boeing"
icao_model="737-800"
where should the path to this be?
Should be the PMDG 737-800 folder in your community folder
-
sorry, so why it works correctly should I change from "737-800" to "B738"? right?
-
Exactly, because that's how Simbrief use, and the two ICAO code must match for GSX know you are using the same airplane type.
-
icao_model should be "B738", that's the official ICAO code which is also what Simbrief use.
Thanks for everything so far... To clarify the above though... There are a load of similar inconsistencies across other aircraft/developers, if icao_model is expected to be the icao type code from a GSX / SimBrief integration POV...
Fenix A320 - icao_model =A-320
FBW A320 mod & Default Asobo A320neo - icao_model = "A-320neo"
I can't easily check Asobo's or "Heavy Division's" B78X cos it doesnt have a traditional aircraft.cfg
There are obvious errors in PMDG's B738, so no need to go over that again
Asobo's SDK seems a little ambiguous as purpose of icao_model, and what strings developers should be conforming to
The ICAO model name of the plane. It can be different to the atc_model field. For example the Textron 172 Skyhawk:
icao_model = "172 Skyhawk"
However, there is the icao_type_designator= string, which does seemingly from my admittedly rather layman's perspective, more widely conform to aircraft ICAO standards across all possible aircraft-types (and developers)
PMDG have admitted that the atc_model= and icao_type_designator= strings were an oversight, so can be manually corrected, pending an update from PMDG
https://forum.pmdg.com/forum/main-forum/general-discussion-news-and-announcements/212560-24aug22-pmdg-announces-release-of-pmdg-737-800-for-microsoft-flight-simulator?p=212717#post212717
-
However, there is the icao_type_designator= string, which does seemingly from my admittedly rather layman's perspective, more widely conform to aircraft ICAO standards across all possible aircraft-types (and developers)
It's in fact very easy to get confused because all these different naming standard, I said GSX checks for the icao_code but, in fact, that's how it's called in SimBrief, more precisely is the <icaocode> tag in their returned XML for the current dispatch.
However, when checking with the airplane, GSX of course checks the icao_type_designator, as it should be, I took the default A320 Asobo as an example, which indicates A20N (correct) and the Fenix A320 (correct), so I think there's no doubt this IS in fact the official ICAO code for the airplane type.
-
However, when checking with the airplane, GSX of course checks the icao_type_designator, as it should be, I took the default A320 Asobo as an example, which indicates A20N (correct) and the Fenix A320 (correct), so I think there's no doubt this IS in fact the official ICAO code for the airplane type.
Brilliant, thanks for confirming this is the property in question when GSX checks SimBrief dispatch.
I'd maybe somehow gotten myself confused when folks started talking about icao_model
-
this entry change leads to the next error so only 9 pax are loaded so this does not work either
-
this entry change leads to the next error so only 9 pax are loaded so this does not work either
This usually happens when the scenery's data is not loaded correctly by GSX or when jetway data and scenery data mismatch. What airport was it and what scenery? Was it a marketplace airport? And if 3rd party, did you exclude the GSX jetways for that airport?
-
this entry change leads to the next error so only 9 pax are loaded so this does not work either
This usually happens when the scenery's data is not loaded correctly by GSX or when jetway data and scenery data mismatch. What airport was it and what scenery? Was it a marketplace airport? And if 3rd party, did you exclude the GSX jetways for that airport?
LZSH from fsdreamteam so if it does not run there you know that gsx still has a quirk :D
-
this entry change leads to the next error so only 9 pax are loaded so this does not work either
Which means there was another condition that hasn't been satisficed to enable Simbrief integration, so GSX estimated from the payload, which might have been low at that time. Please read again all conditions to have Simbrief enabled at Page 60 of the manual.
If you want to check what's really happening, enabled logging in the GSX Settings and all interaction with Simbrief will be logged as well
-
It looks like the PMDG 737-800 has the incorrect ICAO code listed in the aircraft.cfg- they have it as B737 and 737-700
Correct the entries so they look like this:
[General]
atc_type="BOEING"
atc_model="B737"
Category = "airplane"
icao_type_designator="B738"
icao_manufacturer="Boeing"
icao_model="737-800"
This worked perfectly for me...I now get the correct simbrief PAX Number..it was driving me nuts
-
LZSH from fsdreamteam so if it does not run there you know that gsx still has a quirk
The scenery used doesn't have any effect on the passenger number calculation, which is done either by reading the airplane payload OR from Simbrief.
-
this entry change leads to the next error so only 9 pax are loaded so this does not work either
This usually happens when the scenery's data is not loaded correctly by GSX or when jetway data and scenery data mismatch. What airport was it and what scenery? Was it a marketplace airport? And if 3rd party, did you exclude the GSX jetways for that airport?
I spent 5 hours last night trying to get GSX to NOT load 9 passenger, and instead load according to my simbrief plan. First I had to correct PMDG's error in the aircraft.cfg and then I had to regenerate my simbrief plan because it was out of date by the time I got the PMDG error sorted out - ALL COMPLETELY UNNECESSARY WHEN EXTRACTING PASSENGER LOAD FROM SIMBRIEF PLAN.
Quite honestly, Umberto, I believe you have created support issues for yourself: there is no reason to require verification of aircraft model, type, size, or whatever when setting passenger number from simbrief - if the pilot doesn't care to make sure the aircraft being used matches the simbrief flightplan, what do you or GSX/Coatl care - it just adds complexity that serves no purpose.
Another status check that is useless and will cause exactly the same problem of not loading the number of passengers in the simbrief plan is if the scheduled departure time of the plan is wrong for the current time - once again you are only creating support cases and more work for you and your staff - what do you or GSX/Coatl care if the times are wrong - if the pilot doesn't care why should you.
A better way would be a warning message for both cases, with the options to ignore the error, or ignore the simbrief plan. A best way would be to ignore both errors and just continue loading the simbrief passenger count.
Please don't make it more complex than is necessary, and remove these superfluous verification/checks, and let us just use GSX the way WE want.
-
With all due, you had to regenerate your simbrief profile and that made you upset? Pfft.
-
With all due, you had to regenerate your simbrief profile and that made you upset? Pfft.
That's what you got out of my post?! Comprehension challenged are we?
-
... there is no reason to require verification of aircraft model, type, size, or whatever when setting passenger number from simbrief - if the pilot doesn't care to make sure the aircraft being used matches the simbrief flightplan, what do you or GSX/Coatl care - it just adds complexity that serves no purpose.
Seriously? So If I plan a Simbrief flight for a 777-200ER, with 320 passengers and 148,000 of fuel on board and then start the flight with a 737... You don't think GSX should care? That makes no sense. Of course it matters, and of course GSX should check...
Umberto - do we need to correct the 700 as well? I hadn't noticed any problems loading, but that might just be me not paying attention. :D
[General]
atc_type="BOEING"
atc_model="B737"
Category = "airplane"
icao_type_designator="B737"
icao_manufacturer="Boeing"
icao_model="737-700"
-
Umberto - do we need to correct the 700 as well?
I see it's fine in the file you posted: B737
-
Oh... I was going by this:
icao_model should be "B738", that's the official ICAO code which is also what Simbrief use.
I thought we needed to change icao_model="B737"
-
https://docs.flightsimulator.com/html/Content_Configuration/SimObjects/Aircraft_SimO/Aircraft_Config_Definition.htm
Here's the different fields and what they're supposed to read. If there's any developer using them incorrectly, then raise a ticket with them so that everyone can start using everything exactly the same and how it should.
-
I thought we needed to change icao_model="B737"
No, read the previous posts, the parameter to change is icao_type_designator.
-
I have a strange issue with the Fenix. Is obviously can’t read the eight passsanger numbers. For example 145 pax like simbrief said. So I only get 98 for example but when I start deboarding. It reads and deboard 145. Just to clarify it for me
1 I complete my flight plans with sim brief creat a flight plan etc.
2 open up the Fenix EFB got to the simbrief “app” load my flight into the EFB
3 open Fenix app load the flight plan there.
4 open GSX(than GSX should read the Pax number) REQUEST FUEL Catering.
5 than spart Boarding via GSX.
Did I missing anything ?
Anything in a wrong order ? Estimate Pax are of Siembrief NAME is correct inside the GSX settings.
Best regards
-
Well I'm not sure why one would do that, but if it's not important to that person how does it suddenly become important to break the function of using the simbrief passenger manifest.
...and yet here you are still wasting time trying to fix it.
-
what is the problem that gsx can't manage to load the correct number of PAX? D here is written so much because you can no longer see through
I especially not because I have to work with translator and the sentences sometimes do not make sense :D
Umberto you're swiss you could tell me in german what exactly the problem is now?
I am registered with simbrif correctly and the config file I have also changed please explain to me what is wrong I do not understand it ?
-
...and yet here you are still wasting time trying to fix it.
Fix what? Nothing is broken. I changed the 800 and the correct # of pax loaded.
-
what is the problem that gsx can't manage to load the correct number of PAX? here is written so much because you can no longer see through
There's no problem whatsoever with GSX and the number of passenger, the only problem here is, the PMDG 737-800 has the wrong icao_type_designator in its aircraft.cfg, PMDG has already said it was an oversight, and they'll fix it, or you can fix it yourself in 5 minutes.
-
...and yet here you are still wasting time trying to fix it.
I'd be wasting way more time if I had to explain why GSX ignores the airplane type, so it would try to fit 400 passengers on a 737, just because your latest flight used an 747. Most people will assume GSX has a bug, and your suggestion to make it more complex with warnings will only make worse what is being handled automatically by checking the airplane type, which is obviously the one sane choice.
And yes, I even consider complicating the code further, making a complex heuristic translation table from "what the heck the developer might have called the airplane", into the proper icao type. And I decided to not do it, it's an international agreed standard with a unique code for a good reason, no need to make GSX any more complex than already is.
-
I don't understand how you consider silently erroring and not using SB passenger manifest as being "handled automatically." Why would you have to explain anything...if the customer attempts to use the wrong aircraft, I hardly see how that's your problem, or how the customer could consider it your problem. When I allowed GSX to estimate passengers it tried to load 214 on my 738 - hardly realistic. As far as making it more complex, that's why I said the best solution is to ignore the aircraft type - if the customer has ignored it and chosen the wrong type, why does it make sense to question them. But the whole point is that I wasn't even using the wrong type...and developers employ bad data all the time...a perfect example being the case with PMDG - arguably one of the best aircraft developers around - just ignore it! Seems to me NOT ignoring it is the only reason this thread exists!
-
I don't understand how you consider silently erroring and not using SB passenger manifest as being "handled automatically."
It's exactly that.
if the customer attempts to use the wrong aircraft, I hardly see how that's your problem, or how the customer could consider it your problem.
Of course the customer will think it's a GSX bug, when it will see 400 passengers magically fit in a 737.
When I allowed GSX to estimate passengers it tried to load 214 on my 738 - hardly realistic.
Only because the icao type was wrong in the airplane itself. See ? Even you make the easy mistake of blaming GSX for a problem in the aircraft, imagine how it would look like if GSX called 5 Buses worth of people instead! The 737-800 can carry up to 189 people, that's not as big as an "error" of using the wrong type in Simbrief without checking if the plan was for the correct airplane.
As far as making it more complex, that's why I said the best solution is to ignore the aircraft type - if the customer has ignored it and chosen the wrong type, why does it make sense to question them.
That's why I explained multiple times I don't agree with this, and your solution is way worse.
Seems to me NOT ignoring it is the only reason this thread exists!
The only reason this thread exist is because PMDG is very popular and made a very excusable mistake, which will be fixed soon and nobody will ever remember this thread. But if we did the mistake of ignoring the airplane type, GSX will be always at risk of loading numbers *completely* off.
-
Uninstalled - How do I get a refund?
-
How do I get a refund?
And what this is supposed to even mean ? Now you want a refund because you don't agree with a design choice that has been explained thoroughly ? For an issue that was caused by a *trivially* easy to fix "bug" ( I won't even call it a real bug ) in another product, with GSX performing as designed ?
-
It means I made a mistake, I should have read and watched more reviews before impulsively buying, I won't use it because I prefer to fly and not spend a lot of time fiddling and customizing.
Umberto, I own almost all your products 3X now between FSX, P3D and MSFS, including GSX, and will continue to buy your airports because they're some of the best. I've paid my dues for the last 30 or so odd years fiddling with flight sims and related software, and after all that time I find myself infinitely less tolerant of having to spend time doing everything except what flightsimming is about - flying. I expect you'll have a strong customer base for GSX and I hope you make a ton of money from it - heaven knows it took a ton of work to get it here - this experience has proven it's just not for me anymore.
-
It means I made a mistake, I should have read and watched more reviews before impulsively buying, I won't use it because I prefer to fly and not spend a lot of time fiddling and customizing.
About the issue that has been discussed here, the only thing you had to fiddle with, was the aircraft.cfg of the airplane. Somehow I guess if you go over the PMDG forums saying the requirement to having to fiddle with the aircraft.cfg to fix a problem would warrant a refund request, won't probably be taken too well. But that's just my guess, you can always try...
-
Enjoy my donation. Clearly you have LOTS of other GSX issues to deal with.
-
Enjoy my donation. Clearly you have LOTS of other GSX issues to deal with.
You got it backwards: I already issued a refund to you so, you'll be able to use it for free, at least until you change your hardware.
-
This is my first post I just read this thread I cannot believe this customer somiller sometimes I guess you just can't fix stupid
Have paid for and been using GSX since day one, and after reading the manual over twice I have not had one problem best thing since sliced bread
-
how to fix this now? as said the config of the 738 is adjusted nevertheless GSX works incorrectly so
I want now finally a solution that works >:(
-
how to fix this now? as said the config of the 738 is adjusted nevertheless GSX works incorrectly so
An unidentified airplane type is only one of the possible reason why Simbrief is not active, the others all indicated at Page 60 of the GSX Manual.
If you are sure all the conditions has been satisfied in your case, you can enable logging in the GSX troubleshooting section and, when you activate a gate, all information about SimBrief will be logged there, indicating why the dispatch hasn't be loaded.
-
this entry change leads to the next error so only 9 pax are loaded so this does not work either
It actually DOES work. Make sure you've corrected the appropriate lines as detailed above in this thread.
-
this entry change leads to the next error so only 9 pax are loaded so this does not work either
This usually happens when the scenery's data is not loaded correctly by GSX or when jetway data and scenery data mismatch. What airport was it and what scenery? Was it a marketplace airport? And if 3rd party, did you exclude the GSX jetways for that airport?
yes they are the ones from the market these are versxhlüsselt and yes I have not taken the jetway of gsx but the standard of the third party
-
yes they are the ones from the market these are versxhlüsselt and yes I have not taken the jetway of gsx but the standard of the third party
Yes, preventing an airport to have its jetways replaced by GSX should be done for 3rd party airports, but if they are bought on Marketplace, it's not enough, GSX won't be able to use it anyway.
This should change in the future, when the new API from SU10 will be out of Beta, assuming it will be also updated to add some things we are sill missing and we obviously asked to Asobo to be added ( data about Jetways, Jetway links and Runways Starts are missing in the current Beta ), we might possibly get away with the airport cache altogether, solving lots of issues and being able to read encrypted airports as well.
-
Fenix A320 - Passengers load for about 5 seconds and then stop. The number of passengers is correct in the log and timing is set to normal.
-
that means it can be that after SU 10 GSX still can not work with the data because asobo has not opened the API far enough so that you can work with it?
-
that means it can be that after SU 10 GSX still can not work with the data because asobo has not opened the API far enough so that you can work with it?
I said which features are missing *today*
- Jetways
- Jetway links
- Runway starts
Of course, as soon as it came out, we reported this and asked to be added, because knowing where the Jetways are is very important for GSX, but we can't possibly know if the final version will have it, and if and when it will be improved with later updates.
We already have some code working with the Beta, but you can't expect we'd release something the same date SU10 comes out, if the API remains the same as is today, we'll have to find alternative ways to find jetways, not impossible, but it will require extra coding.
Jetway links are even more complex (=not possible), because they are in the .BGL and, not being Simobjects, they cannot even "searched" at runtime like jetways so, if the API doesn't improve, we might have to restrict passengers walking only through the actual jetway, not continuing through the bridge (even if this could be fixed with customization).
-
Fenix A320 - Passengers load for about 5 seconds and then stop. The number of passengers is correct in the log and timing is set to normal.
Any update on this? Your simbrief matched, now wondering if it is indeed a bug w/ GSX?
-
I just tried it again and same thing. It properly pulled the passenger count from Simbrief but loaded them in about 5 seconds.
Also, the fuel truck showed up when requested, asked me to enter the fuel quantity (I did per the manual), and then drove away immediately. I would say this happens 75% of the time between Fenix and PMDG.
Also, when I selected "board passengers" the jetway immediately disconnected leaving the aircraft door open. The jetway was then "awaiting boarding" when I tried to reconnect it which was slightly amusing (at this point you have to laugh).
The pushback with the latest update is extremely janky. The aircraft just bobbles up and down the whole time. The disconnect jolt has not been resolved per the release notes and this new pushback issues has not been introduced that I haven't seen yet (it was tug with towbar).
I feel like getting this program to work properly for one complete flight from end to end will be like winning the lottery. And yes, I've RTFM several times and have spent far too much time reading this forum.
-
I just tried it again and same thing. It properly pulled the passenger count from Simbrief but loaded them in about 5 seconds.
Have you used a gate in which the stairs have been disabled in the airport profile ? If yes, this issue has been fixed in today's update.
Also, the fuel truck showed up when requested, asked me to enter the fuel quantity (I did per the manual), and then drove away immediately. I would say this happens 75% of the time between Fenix and PMDG.
This because the quantity you entered wasn't higher than the quantity you had before calling the GSX fuel truck. Or the quantity changed for other reasons, like the plane refueling itself.
Also, when I selected "board passengers" the jetway immediately disconnected leaving the aircraft door open. The jetway was then "awaiting boarding" when I tried to reconnect it which was slightly amusing (at this point you have to laugh).
You don't say which airplane you used. The Fenix controls the jetway too so, if it happen the commands from the Fenix and GSX cross with each other, that's exactly what will happen. Of course, GSX cannot possibly know exactly when the Fenix calls the jetway and vice-versa, until there will be a proper communication between the two.
I tested the Asobo A320 and the PMDG 737, and I can't see any bobbling or any jumps on disconnect. With a Towbar. Without it, it would be exactly as it was before, unless the gear raise is disabled.
The pushback with the latest update is extremely janky. The aircraft just bobbles up and down the whole time. The disconnect jolt has not been resolved per the release notes and this new pushback issues has not been introduced that I haven't seen yet (it was tug with towbar).
There was a reason to freeze the airplane, and it was to prevent the aircraft "bobbling", but since users complained about the bump on disconnect, it's difficult to say which one to choose.
-
now tell me where the bug is i am already standing in LSZH on a gate without a jetway and yet it only loads 9 pax this is clearly a bug from you so gsx >:(
-
now tell me where the bug is i am already standing in LSZH on a gate without a jetway and yet it only loads 9 pax this is clearly a bug from you so gsx
I suggest to check facts first, before saying "clearly a bug", nothing is "clear" with a so sparse report of the situation, which of course is what is required to know is is *really* a bug.
HOW you set the passenger number ? Are you using SimBrief ? If yes, what the message under the SimBrief button says ?
If you are not using SimBrief, have you read the GSX manual at Page 14, which explain how the Passenger Number is calculated when SimBrief is not used, based the payload. So, if this is your case, how was your Payload when you started GSX ?
-
I have written you this several times here I write it for the last time
simbrif alias is registered
pmdg in fmc loaded (PAX,fuel,suitcase)
machine was also tested on your airport (LSZH) to see if there the PAX are loaded properly
what i don't understand is that it can't connect to simbrief even though everything is correctly entered
-
I have written you this several times here I write it for the last timewhat i don't understand is that it can't connect to simbrief even though everything is correctly entered
I read all previous your posts im this thread, and nowhere you said which problem you had, exactly. Now, finally, you are saying it cannot connect to SimBrief, which might be caused by many issues, like missing username, wrong username, SimBrief not replying, your firewall blocking the connection, etc.
So, please follow the instructions in the Stick thread named "How to report an error", and post your Couatl.LOG made AFTER you see the SimBrief button being red with the conection error message
-
I have written you this several times here I write it for the last timewhat i don't understand is that it can't connect to simbrief even though everything is correctly entered
I read all previous your posts im this thread, and nowhere you said which problem you had, exactly. Now, finally, you are saying it cannot connect to SimBrief, which might be caused by many issues, like missing username, wrong username, SimBrief not replying, your firewall blocking the connection, etc.
So, please follow the instructions in the Stick thread named "How to report an error", and post your Couatl.LOG made AFTER you see the SimBrief button being red with the conection error message
so I do not understand why he does not want to
and i can not upload the log your site does not accept the file type
the link is the log
https://drive.google.com/file/d/1YvLSRD5A6jex8u0LRKoq8Xtv-RA1bQE_/view?usp=sharing
-
so I do not understand why he does not want to
Since noone bothered to reply:
The logfile states "SimBrief aircraft B738 doesn't match MSFS aircraft B737". Make sure that for the 737-800 the aircraft.cfg states:
icao_type_designator="B738"
Or if you are actually flying the B737-700 in MSFS, make sure to select the correct simbrief profile for this aircraft type so that it matches your MSFS aircraft.
-
so I do not understand why he does not want to
Since noone bothered to reply:
The logfile states "SimBrief aircraft B738 doesn't match MSFS aircraft B737". Make sure that for the 737-800 the aircraft.cfg states:
icao_type_designator="B738"
Or if you are actually flying the B737-700 in MSFS, make sure to select the correct simbrief profile for this aircraft type so that it matches your MSFS aircraft.
I also think you have to do this "workaround" on EVERY livery you have. Such nonsense.
-
Does anyone know what are the correct inputs for Longitude? Tried the below edits since SU10 opened aircraft.cfg file and still get GSX Does not recognize Aircraft Type when I reload SimBrief.
atc_type = "CITATION"
atc_model = "C700"
Category = "airplane"
icao_type_designator = "C700"
icao_manufacturer = "CESSNA"
icao_model = "LONGITUDE"
icao_engine_type = "Jet"
icao_engine_count = 2
icao_WTC = "M"
Thank you in advance.
-
still get GSX Does not recognize Aircraft Type when I reload SimBrief.
C700 is the official icao type for the Longitude but, it's not as if GSX has any knowledge of real icao type codes, the only thing that matters, is the code must *match* the one you have on SimBrief so, check it's C700 there as well.
And, when you press "Reload Simbrief" button, you should have seen a message from GSX if the problem was really the airplane code not matching, because a text on the top left will list both the code in your airplane and the code you have on SimBrief.
It really doesn't matter what code you use, as long the two are the same.