BACARS Version 8 - Major Overhaul of BACARS / Planning Portal

[Mariano]

Simon,

I ran a quick LSZH runway 28 scenario (I believe that all runways at LSZH have elaborate ETPs).

Returned RTOW was low (as expected), but there were no ETP notes included.

Does this mean that CARD was giving me an RTOW applicable to the most-limiting SID instead of a higher RTOW commensurate with an ETP?

How does CARD decide when and where an ETP applies? Does it consult a database of worldwide ETPs from a specific source?

Thank you and best regards,

Mariano

[skelsey]

Hi Mariano,

The way it works is that I have an offline tool which analyses the track of each SID against terrain (from the NASA SRTM DEM model) and obstacles (currently in a 2.5NM corridor around the SID track which narrows closer to DER -- it's not exactly PANS-OPS but at the moment it's probably a reasonable approximation).

If the gradient required for a SID exceeds 3% (CS-25 OEI climb gradient certification requirement for 4-engined aircraft) the runway is flagged as requiring an ETP. The tool then automatically calculates an ETP; assuming it can find a solution that offers a meaningful improvment on the existing SID gradient it will then use that. It groups together all SIDs with common 'gate' fixes and ETPs and writes the results to a file which is then shown in the Perf Notes section.

Alongisde this, the ETP analysis/generation tool generates a set of 'synthetic' obstacles that match the gradient required for either the ETP or the worst-case SID. These are added to the CARD obstacle database in a seperate section, so when you send a performance request CARD looks at the database and if a set of synthetic obstacles exist for the runway it uses them for the obstacle-limited takeoff weight and acceleration height calculations, and if not it simply falls back to the existing 'straight out' obstacle database.

One of the difficulties is that reliable (and easy-to-obtain and process) obstacle data is quite hard to come by outisde of the US (which provides a daily Digital Obstacle File). My obstacle database tool currently draws from the FAA DOF for the USA and OpenAIP for worldwide obstacles but I think there is still a bit of work to do to improve the reliability of this process as the OpenAIP data is sometimes inconsistent and difficult to parse resulting in relatively sparse coverage.

Looking at the analysis for LSZH 28 I get the following:

Code Select Expand

----------------------------------
[OBSTACLES_EFFECTIVE] DEBUG OUTPUT:
----------------------------------
LSZH;28;0.0;0.0;SID
LSZH;28;13671.3;21.4;SID
LSZH;28;15190.3;138.2;SID
LSZH;28;21575.3;169.4;SID
LSZH;28;23094.3;282.5;SID
LSZH;28;38611.2;339.9;SID
LSZH;28;40130.3;598.8;SID
LSZH;28;156381.0;684.3;SID
LSZH;28;157900.1;716.9;SID
LSZH;28;159419.1;914.6;SID
LSZH;28;160422.9;922.1;SID
LSZH;28;168018.1;1153.3;SID
LSZH;28;169537.1;1451.1;SID

--------------------------------------------------
ANALYSIS SUMMARY FOR LSZH RWY 28
--------------------------------------------------
SID DEGE1X    Grad=2.30%   SelfClears=True   Gate=-
SID DEGE1Y    Grad=2.30%   SelfClears=True   Gate=-
SID DEGE3W    Grad=2.30%   SelfClears=True   Gate=-
SID GERS2W    Grad=2.30%   SelfClears=True   Gate=-
SID SAT2W     Grad=0.00%   SelfClears=True   Gate=-
SID VEBI1X    Grad=2.30%   SelfClears=True   Gate=-
SID VEBI1Y    Grad=2.30%   SelfClears=True   Gate=-
SID VEBI4W    Grad=2.30%   SelfClears=True   Gate=-
SID ZUE3V     Grad=2.30%   SelfClears=True   Gate=-

EOSID Required: False

=== GROUPED SID/EOSID ACARS BLOCK ===

[DEBUG] MagVar at DER (WMM): 3.08°
[DEBUG] Emergency ref navaid IZW magvar: 3.08°

=== DONE ===

So yes, it will have been giving you an RTOW applicable to the most limiting SID (~2.3% gradient).

Essentially, when I look at the debug output although it is finding some terrain (the most limiting being near the DER in the first few segments of the departure) it's not really finding many obstacles. The RW ETPs for ZRH 28 I have are only required for a failure inside KLO D2.3 so that does suggest the limiting factor is fairly close in.

Looking at LSZH 34 on the other hand my tool does come up with an ETP:

Code Select Expand

----------------------------------
[OBSTACLES_EFFECTIVE] DEBUG OUTPUT:
----------------------------------
LSZH;34;0.0;0.0;EOSID
LSZH;34;16709.3;26.4;EOSID
LSZH;34;19747.4;32.3;EOSID
LSZH;34;21266.4;41.8;EOSID

--------------------------------------------------
ANALYSIS SUMMARY FOR LSZH RWY 34
--------------------------------------------------
SID DEGE1J    Grad=2.30%   SelfClears=True   Gate=-
SID DEGE4H    Grad=3.53%   SelfClears=False   Gate=ZH503
SID DEGE5F    Grad=2.30%   SelfClears=True   Gate=-
SID GERS1H    Grad=3.03%   SelfClears=False   Gate=BREGO
SID SAT2F     Grad=0.00%   SelfClears=True   Gate=-
SID SAT2H     Grad=0.00%   SelfClears=True   Gate=-
SID VEBI2K    Grad=2.30%   SelfClears=True   Gate=-
SID VEBI4H    Grad=2.30%   SelfClears=True   Gate=-
SID ZUE5F     Grad=2.30%   SelfClears=True   Gate=-

EOSID Required: True
Preferred EOSID: Right (0.37% net)
Left EOSID:  0.56%
Right EOSID: 0.37%

=== GROUPED SID/EOSID ACARS BLOCK ===
VEBI/ZUE SIDS
NO RESTRICTIONS

DEGE SIDS
ENG FAIL BEFORE ZH503
CLB RWY TRK TO IZS
1.6DME
AT IZS 1.6DME TURN RIGHT
TRK 107M
CONTINUE TRK 107M TO IZS
6.7DME
PROCEED DIRECT ZUE
HOLD AT ZUE INBD 260 RIGHT TURNS
MIN 5400FT

GERS SIDS
ENG FAIL BEFORE ZH503
CLB RWY TRK TO IZS
1.6DME
AT IZS 1.6DME TURN RIGHT
TRK 107M
CONTINUE TRK 107M TO IZS
6.7DME
PROCEED DIRECT ZUE
HOLD AT ZUE INBD 260 RIGHT TURNS
MIN 5400FT

SAT SIDS
TERRAIN CLEARANCE NOT ASSESSED ALONG
RADAR VECTOR SIDS - ENSURE SSA
CAN BE ACHIEVED BEFORE ACCEPTING
RADAR HEADINGS

[DEBUG] MagVar at DER (WMM): 3.08°
[DEBUG] Emergency ref navaid IZS magvar: 3.08°

=== DONE ===

I'll have a look at the obstacle database tool and see if I can improve the quality of the data going in to it!

[Mariano]

This is very impressive work, even with the stated official data limitations.

The fact that you came up with your own ETP-generating tool alone is quite remarkable (I have always been very interested in engine-out procedures (on takeoff, cruise escape routes, and ETOPS diversions)). This addition exponentially improves CARD, turning it into something that I was not expecting (as in creating its own ETPs).

Thank you for your and Gary's continued contribution to the community.

Best regards,

Mariano

[Mariano]

Gary/Simon,

Which exact value does CARD use as Maximum Structural Takeoff Weight? Can the user edit said value to match specific model configuration?

Thank you,

Mariano

[skelsey]

Hi Mariano,

By default CARD uses a maximum structural TOW of 396,890kg (or Lbs equivalent if BACARS is set to LBS).

It is in principle configurable (CARD has the ability to accept a custom max structural TOW value from BACARS) but I don't think it's possible yet to set that option in BACARS -- I'll check with Gary.

[Mariano]

Thank you, Simon.

Best regards,

Mariano

[FlyItLikeYouStoleIt]

CARD: latest version: not accepting -2 or M2 for a temp in C below freezing.

Also, I swear I saw a document somewhere with all the corrections codes but now cannot find it.

[Gary Oliver]

Happy new year!

Card doesn't accept any values less than 0 as per the real thing.

We really should write a manual

Cheers
G

[skelsey]

The CARD user guide (including correction codes) can be found on Page 1 of this thread: https://drive.google.com/file/d/1-Y1nSKMHLC0KU4XvHlOD4DDCbAiguXj9/view?usp=drivesdk

Best,

Simon

[FlyItLikeYouStoleIt]

Perfect. I knew I had seen it somewhere. Incidentally the changelog shipped with BACARS still contains a reference "Card now accepts M or - for temperature" for the old CARD (v4.04). This confused me!

[Mariano]

Gary/Simon,

The way that I understand the regulations regarding takeoff certification is as follows (let's assume a two-engine FAR Part 25 turbojet).

The OEI minimum required climb gradient is 2.4%. This gradient is then reduced by 0.8% in order to add a margin of safety, which gives us 1.6%.

No obstacles or terrain are allowed to penetrate above this 1.6% limit, even though the aircraft must be capable of a 2.4% climb gradient.

I believe that the safety reduction for three and four-engine turbojets is also 0.8% (I need to confirm). Does CARD need to reduce the 3.0% gradient by 0.8% and then flag any SIDs or departure tracks whose obstacle or terrain penetration exceeds 2.2% in order to then calculate ETPs (as opposed to the current 3.0%)?

I could very well be wrong about this. I was just checking to see if anyone agrees with this assessment.

I remember reading about this a while back, but I could search for the correct verbiage if it is not immediately evident that this is the case.

Once again, thank you for all your work on BACARS.

Best regards,

Mariano

[skelsey]

Gary/Simon,

The way that I understand the regulations regarding takeoff certification is as follows (let's assume a two-engine FAR Part 25 turbojet).

The OEI minimum required climb gradient is 2.4%. This gradient is then reduced by 0.8% in order to add a margin of safety, which gives us 1.6%.

No obstacles or terrain are allowed to penetrate above this 1.6% limit, even though the aircraft must be capable of a 2.4% climb gradient.

I believe that the safety reduction for three and four-engine turbojets is also 0.8% (I need to confirm). Does CARD need to reduce the 3.0% gradient by 0.8% and then flag any SIDs or departure tracks whose obstacle or terrain penetration exceeds 2.2% in order to then calculate ETPs (as opposed to the current 3.0%)?

I could very well be wrong about this. I was just checking to see if anyone agrees with this assessment.

I remember reading about this a while back, but I could search for the correct verbiage if it is not immediately evident that this is the case.

Once again, thank you for all your work on BACARS.

Best regards,

Mariano

Hi Mariano,

Having looked in to this a bit - I believe you are correct, we should be using net rather than gross gradients for the ETP threshold.

As you say, for 4 engined aircraft the CS-25 required gross gradient is 3%, with a 1% deduction to give 2% net, so I have adjusted the threshold accordingly. I need to tweak the SID analysis process slightly as well since at the moment we are looking at the full length of the SID which in some cases is leading to some odd results, whereas I think we can be a bit smarter in how we determine the 'gate' before which an ETP is required.

I have updated the CARD airfield and ETP database for AIRAC 2601 on the server

[Mariano]

Thank you, Simon. :-)

Best regards,

Mariano

[Mariano]

Simon,

Would it help to simplify the SID ETP logic if you stopped ETP determination once the net gradient reaches the respective MSA as opposed to calculating for possible gates all the way to the end of the SID?

Just a quick thought; more research needed, I'm sure.

Best regards,

Mariano

[skelsey]

Simon,

Would it help to simplify the SID ETP logic if you stopped ETP determination once the net gradient reaches the respective MSA as opposed to calculating for possible gates all the way to the end of the SID?

Just a quick thought; more research needed, I'm sure.

Best regards,

Mariano

Hi Mariano,

Yes, I have been working on exactly this (plus a few other refinements to the EOSID logic and text -- smoothing out DEM artefacts very close to the runway, defining the EOSID based on a dynamic gate altitude etc).

So far seems so good in testing; I hope to upload the updated database to the server tomorrow.

Best,

Simon

[Mariano]

Excellent news! Eagerly awaiting new release. Thank you, Simon.

Best regards,

Mariano

[skelsey]

Databases now updated on server.

Code Select Expand

[b]05 Feb 2026[/b]
CARDPerf.Core v1.0
- Improved ETP logic and calculations - now calculates "gate" altitude above which ETP not required and assesses ETP requirements based on climb to this point
- Terrain database smoothed for ETP calculations to avoid small artefacts close in causing ETP to be required when not really necessary
- ETP text improved (now shows correct SID fix names instead of truncated versions)

CARDObstacleDB v1.0
- Initial version of Obstacle, Intersection and ETP generation tool used to generate the CARD database
- Improved obstacle database with UK AIP data

[Mariano]

Thank you!

Best regards,

Mariano

[skelsey]

Tiny update to CARD:

Code Select Expand

12 Feb 2026
Added "(BACKTRACK)" to F/L identifier in output if runway entry point is not full length and backtracking required

[skelsey]

A few minor fixes over the last couple of weeks, now all reflected on the live server:

Code Select Expand

27 Feb 2026
CARDPerf.Eosid v1.1
- Fixed issue where ETP procedure text was mixing AMSL and AAL
- ETP gate altitudes now properly dynamically calculated

CARDObstacleDB v1.1
- Fixes to improve memory usage

CARDPerf.Dem v1.1
- Now uses IDisposable to reduce memory usage and ensure proper cleanup of resources

19 Feb 2026
- Database updated to AIRAC 2602

14 Feb 2026
CARDObstacleDB v1.0.1
- Now supports manual intersection database to enrich OSM data

13 Feb 2026
CARD v1.4.1.1
- Wind calculation now fully accurate (computations now use double rather than int)
Let me know of any intersection anomalies you come across (e.g. BACKTRACK showing where it shouldn't etc) as I can now manually add/override the OSM-based data.