UK (EGxx) SIDs bug? PP0705 + PSS ABPro

[Guest BigJacko]

Dear Terry,First - a huge thanks for the service you have provided over the years to us out here in the big room, who are very much reliant on your kind efforts to keep our online flying in track with the current real world. I know there are others out there in the field writing SIDs and STARs for a variety of planes, but I must be honest and say I have learned more from you over the last couple of years than any other contributor in this arena, and for that I am truly grateful. :-beerchugOkay - now to the wrinkle I think have just discovered in your latest 0705 cycle* which I downloaded for the PSS Airbus Pro series recently. On many of the SIDs (in PSSSID.DAT) I notice that there are legtypes starting with 6, usually an "IF" to begin with, then an as-expected sequence of legs (again all type 6) then ending up with a final legtype 5 which has also a trackcode of "IF"! I'm not sure I entirely follow the logic of having a SID end with a type 5 Initial Fix, but anyway...:-hmmmThe problem is, the PSS A320 FMC will 'see' precisely NOTHING of this SID, at all, when it is chosen in the box. :(There are also some EGxx SIDs which clearly are genuinely intended to have multiple legtypes 6, 5 & even 4 sometimes... and with significant numbers of legs or which have multiple transition options... and in some cases, (mainly in the type-6-followed-by-type-5-with-more-than-just-a-single-"IF" scenario), the PSS A320 FMC will show only the latter part - the type 5 leg - and nothing of the type 6 at all!! Basically half (or more) of the SID is simply missing from the display (but it is there in the PSSSID.DAT file, clearly) :(I've experimented with various hand-mods (and I hope that is okay) to see if I can work out any rhyme or reason - and there are two workarounds, I think...On any SID that's comprised of legtype 6s, and which finishes on a single legtype 5 "IF", you can simply delete the legtype 5 "IF" line completely from the SID, resave the file, and then the FMC will 'see' the whole SID properly in the box. Usually, the type 5 leg iterates the same last point of the type 6 leg anyway (just as an Initial Fix for some reason), so this seems to work fairly safely.But obviously that is not safe to use to solve the SIDs that have legtype 6s followed by multiple legtype 5 lines...In those situations, the best I've been able to come up with is turning the first part (the legtype 6 part) into legtype 4s (maintaining their same position in the file), and leaving the legtype 5s as-is... and they seem okay. I'm not entirely happy about changing these legtypes (it seems, well, conceptually wrong, but I may just be being paranoid)... but at least it gets them working in the PSS 'bus.But then we get into those SIDs that have all legtypes 6, 5 and 4 in them. Strangely - because they generally seem to properly invoke various differing runway-end or SID-to-airway transitions, and these transitions are clearly declared in the code, they seem to work properly (but I haven't fully examined all of them yet). But any SIDs that use all three legtypes without declaring the various transitions? Well, who knows?... clearly there is a risk here.My guess is that something in the new source that you're using is different, somehow, from the data that went before, and this is causing problems on (at least) the PSS Airbus, and quite possibly other planes too, that I've not discovered yet. I notice, for example, that most of the 'homegrown' SIDs available from the freeware developers (to whom I also give my thanks) use legtype 2 almost exclusively, for their EGxx SIDs, (as do most of the payware Navigraph UK SIDs, so I'm told).You may already be aware of all this, Terry, in which case my apologies... But I've seen plenty of cases in the past where nobody's bothered to mention a huge problem that affects only a subset of a userbase, thinking 'the other guy will mention it'. I guess I'm that 'other guy', so forgive me if you've already torn your hair out about this one! ;)If you need a hand, I'm a competent beta-tester (I spent 15 years in the videogames development biz at senior and grunt levels, before retiring), I have a passing familiarity with ARINC-424 and I can code too. I also work for myself and have a fair bit of free time, so I'm more than willing to do some specific tests and help out, if you so desire.Main thing is, reporting the problem in the first place, so let's start there! Thanks again for ALL your fine efforts in this field. You make the online aviation world a better and more realistic place!* just out of curiousity, how are you able to obtain digital-format data for the UK, now that the DAFIF has gone non-public? I would give my right arm to know of such a source that isn't either (a) just plain wrong or (:( expensive!! ) ;)

[Guest staang]

Howdy Neil,>First - a huge thanks for the service you have provided over >the years to us You are welcome.>I have learned more from you over the last couple of years than any >other contributor in this arena, and for that I am truly grateful.That is very nice to hear.>The problem is, the PSS A320 FMC will 'see' precisely NOTHING of this SIDWhat you describe will take some time to check out and I'm sure I will have to spend some more time doing some recoding.>There are also some EGxx SIDs which clearly are genuinely intended to >have multiple legtypes 6, 5 & even 4 sometimes... As I look at my notes PSS uses a route type of 1, 2 and 3 for SIDs and 4, 5 and 6 for STARs. I know my EG.. procedures only use USFIF codes 1, 2 or 3 codes so there would seem to be a conversion problem that's cropped up. >You may already be aware of all this, Terry, in which case my apologies.Nope. I don't get that much feedback. While no one likes to find out that they've screwed up it is necessary to get feedback if one wants to put out a good product and I do.>so forgive me if you've already torn your hair out about this one!Not necessary. This is a fresh hair pulling problem.>If you need a hand, I'm a competent beta-tester You are providing a service just by catching problems and reporting them so in affect you are beta testing the procedures now. Thank you again.>Main thing is, reporting the problem in the first place, I agree. >just out of curiousity, how are you able to obtain digital-format data >for the UK, now that the DAFIF has gone non-public? I hand coded the procedures at all 56 airports from pdf charts obtained from the UK NATS with their permission.RegardsTerry

[Guest BigJacko]

Hi again Terry, hope you are well.>As I look at my notes PSS uses a route type of 1, 2 and 3 for>SIDs and 4, 5 and 6 for STARs. I know my EG.. procedures only>use USFIF codes 1, 2 or 3 codes so there would seem to be a>conversion problem that's cropped up. It would seem so, yes, sadly. Looking at your 0705 PSSSID.DAT file, it seems everything in there is using STAR legtype codes instead of SID ones. I hadn't 'clicked' the significance until you mentioned it, but yes... it looks like a conversion issue higher up, with whatever you're using to export out the per-payware-plane versions of the SIDs. I've only looked at this problem in the context of PSS, at this point, please note.>>>You may already be aware of all this, Terry, in which case my>apologies.>>Nope. I don't get that much feedback. While no one likes to>find out that they've screwed up it is necessary to get>feedback if one wants to put out a good product and I do.Your high standards don't go unnoticed, Terry! That is why I am personally very keen to support you in your excellent work, and why I'm so very grateful for all your efforts in documentation, explanation and the like, over the years. Having worked in development myself for many years, I know the value of quality feedback... and similarly, its usual absence, sadly.>>>so forgive me if you've already torn your hair out about this>one!>>Not necessary. This is a fresh hair pulling problem.Oh dear. I'm so sorry - but good will come of it, I'm sure. We can always wear wigs until it's fixed, eh? ;)>>>just out of curiousity, how are you able to obtain>digital-format data >>for the UK, now that the DAFIF has gone non-public? >>I hand coded the procedures at all 56 airports from pdf charts>obtained from the UK NATS with their permission.Good god! In that case, you go even higher in my esteem! I had toyed with the idea, but decided it would take far too long to decipher all the (usually undocumented) different payware planes input-formats, cope with the inconsistencies of even same-manufacturer plane capabilities, work out all the necessary lat-lon points required to turn most of the UK's early 12th Century crystal-radio-set-based SIDs and STARs into something that was truly RNAV (and thus workable across most of the payware planes' FMCs)... plus it would probably be stepping on someone else's toes (if not yours, then Simon Butler's).But certainly, I am more than willing to help out by testing as many as I can, cross-checking charts and performance in those payware planes that I possess, and reporting back, if that will help improve your end-product?To that end, here is an example and review/bugtest of one SID from your latest 0705 set, compared to the equivalent Navigraph 0705 (Rev 1) SID for the same place (which is also non-working, I hasten to note!) I cite the latter here on the basis of journalistic review/critique/comparison for public benefit, so there should be no issue with copyright infringement. As NEITHER of these SIDs work as they stand, Navigraph can hardly object to an open discussion about the practicalities of ARINC424 data as applied to PSS planes anymore than a learned doctor would avoid discussion of disease-cures... if they are truly as interested as you are, in providing the best service to their paying customers). ;)Navigraph 0705 version:[EGPF/NGY3J /RW05 /RW05 ]2, RW05,010, RW05, 55.863475, -4.449064,GOW ,FA, ,052,000.000,000.4,194.9,0.000000,000.0,000,+,00426,00000,060002, RW05,020, XEXUS, 55.923889, -4.336111,GOW ,CF, ,054,000.000,004.9,049.0,0.000000,003.0,000,+,02000,00000,000002, RW05,030, , 91.000000, 181.000000, ,VI, ,338,000.000,000.0,000.0,0.000000,000.0,000, ,00000,00000,000002, RW05,040, ELBAN, 55.954722, -4.504444,GOW ,CF, ,248,000.000,005.4,338.7,0.000000,003.0,000, ,06000,00000,000002, RW05,050, , 91.000000, 181.000000,TRN ,CR, ,237,000.000,000.0,000.0,0.000000,000.0,000, ,00000,00000,000002, RW05,060, NORBO, 55.595833, -4.761944,TRN ,CF, ,189,000.000,017.0,002.5,0.000000,016.0,000, ,00000,00000,000002, RW05,070,  NGY, 55.177500, -4.168611,TRN ,CF, ,146,000.000,022.6,110.9,0.000000,030.0,000, ,06000,00000,00000PlanePath 0705 version:[EGPF/NGY3J /RW05 /NGY]6,RW05,10,XEXUS,55.923889,-4.336111,,TF,,0,0,,0,0,0,0, ,0,0,06,RW05,20,,55.954722,-4.504444,ELBAN,CI,,144,0,,068,0,0,0, ,0,0,06,RW05,30,ELBAN,55.954722,-4.504444,,CF,,248,0,,0,0,0,0, ,6000,0,06,RW05,40,,55.313333,-4.783889,TRN,CI,,237,0,,009,0,0,0, ,0,0,06,RW05,50,NORBO,55.595833,-4.761944,,DF,,0,0,,0,0,0,0, ,0,0,06,RW05,60,NGY,55.177500,-4.168611,,TF,,0,0,,0,0,0,0, ,6000,0,05,RW05,10,NGY,55.177500,-4.168611,,IF,,0,0,,0,0,0,0, ,6000,0,0Notes:1 - PP SIDs no longer adhering to 'fixed-width' delimited fields. This may or not be important, but I'll note them in detail anyway, and you decide. (These particular variable-widths still seem to work, this time - but I know for certain that some PSS navdata files require fixed-width formatting, or they'll break. Notably the PSSAWY.DAT file, in the field where the Airway name is defined. Navigraph messed this up by using variable-width fields on their Rev 1 of 0705, for example! Result... all routes gave an AWY/WAYPOINT MISMATCH ;)) 1a - PP TransitionID idents are not leading-space prefixed where less than 6 characters long. 1b - PP Sequence numbers are not leading-zero prefixed where sequence numbers are less than 99. 1c - PP Fix idents are not leading-space prefixed where less than 6 characters long. 1d - PP Latitude fields are not leading-zero prefixed where shorter than 10 characters long. 1e - PP Longitude fields are not leading-zero prefixed where shorter than 11 characters long. 1f - PP RecNav fields are not trailing-space suffixed where shorter than 4 characters long. 1g - PP Turn fields are not space-filled when blank (i.e. when not L or R). 1h - PP MagCourse fields are not leading-zero prefixed when shorter than 3 characters long. 1i - PP ArcRadius fields are not leading-zero prefixed and trailing-decimal-zero suffixed to 3 decimal places when shorter than 7 characters long. 1j - PP Distance fields are not leading-zero prefixed and trailing-decimal-zero suffixed to 1 decimal place when shorter than 5 characters long. 1k - PP Bearing fields are not leading-zero prefixed and trailing-decimal-zero suffixed to 1 decimal place when shorter than 5 characters long. 1l - PP VertAngle fields are not leading-zero prefixed and trailing-decimal-zero suffixed to 6 decimal places when shorter than 8 characters long. 1m - PP RteDist fields are not leading-zero prefixed and trailing-decimal-zero suffixed to 1 decimal place when shorter than 5 characters long. 1n - PP Speed fields are not leading-zero prefixed when shorter than 3 characters long. 1o - PP Alt1 fields are not leading-zero prefixed where shorter than 5 characters long. 1p - PP Alt2 fields are not leading-zero prefixed where shorter than 5 characters long. 1q - PP TransAlt fields are not leading-zero prefixed where shorter than 5 characters long. 1r - PP initial SID descriptor line not space-padded or fixed-width where characters are shorter than normal (e.g. /NGY at the end, before the closing square-bracket). 2 - PP legtype codes for this SID are actually using STAR codes (6 & 5). In fact ALL PP SIDs in 0705 appear to be using legtypes 4, 5 or 6 instead of valid SID codes (1,2,3) 2a - PP last line of SID is spurious legtype 5 code, resequenced to the starting seq number, and of ARINC424 trackcode type IF. Don't think this should be in this SID at all, really.3 - PP TransAlt is missing. Aerodrome/Procedure Transition Altitude usually appears in the first line, last field, once only per SID.4 - PP using RNP5 Waypoints (e.g. ELBAN) in the RecNav field may yield unpredictable results. It's longer than the nominal field-length (4 chars), and refers to a waypoint that has no radio frequency to use (which is what this column is usually intended for, in ARINC424 type CI, CD, CR, FD, VD, VI & VR trackcodes)5 - PP not using 91.000000 and 181.000000 in latitude and longitude fields where indeterminate path terminators are being created (eg, the two CI lines, where the endpoint is technically unknown).6 - PP starting the SID with a TF (not a valid ARINC424 trackcode for an RNAV SID start leg - try CF or FA)7 - PP ending the SID with an IF (not a valid ARINC424 trackcode for an RNAV SID finish leg - try CF, DF, HA, RF, TF, or VM). NB - if 2a was resolved, and spurious last line removed, the existing line (trackcode 6, type TF) would otherwise be okay.8 - PP (and Navigraph) - ARINC424 trackcode CI is NOT P-RNAV or RNP-RNAV compliant and really shouldn't be used anymore.9 - Navigraph - ARINC424 trackcodes VI and CR are NOT P-RNAV or RNP-RNAV compliant and really shouldn't be used anymore.10 - PP ARINC424 DF trackcodes should not follow flyby path terminators. Given that there is no (known) method to define FLY-OVER waypoints in the PSS SID datafiles, this presumably means that DF should be avoided entirely (even though DF is technically P-RNAV and RNP-RNAV compliant). Furthermore, if the procedure is intended to represent PRE-ARINC424-16 methodology, and a DF leg is required after a flyover, the preceding leg must be coded as DF or CF (not CI as has been used here).-END-I hope that is useful to you, Terry. I'm sure you already know, but just to reiterate, this is in no way meant as 'criticism' (at least not unconstructively), and is intended to be a dispassionate, cold-light-of-day analysis of as many aspects as I could cover, so that they may be documented, and either ruled as unneccessary to change, or taken on board, as you see fit. I don't think Navigraph's source is neccessarily any better than your efforts of hand-coding (and in some ways, judging by some of the non-RNAV trackcodes they're using, I'm fairly surprised if their data is taken from a 'real-world' source, frankly... Someone's going to have a shock when the Glasgow NDB or Turnberry VOR undergoes maintenance, and their FMC SID no longer works! I would've thought ALL realworld procedures would be RNAV compliant by now, and not dependent on radio navaids for position at all, and instead would by now be using humble lat-lons and inertial guidance entirely... but I guess one lives and learns, eh? ;))In case you're not aware, there are some very useful reference materials available on the ECAC/Eurocontrol website, too. http://www.ecacnav.com/content.asp?PageID=175 - has some data from a design workshop (mostly Powerpoint and MSWord doc files). Full of insight and working techniques that the 'real world' procedure designers use.http://www.ecacnav.com/downloads/iss3_0.pdf - Guidance Material for the Design of Terminal Procedures for Area Navigation (DME/DME, B-GNSS, Baro-VNAV and RNP-RNAV).My current ARINC424 bible (seeing as it's virtually impossible to get hold of a genuine official ARINC424 standards document without spending a LOT of cash!). It's a 217 page PDF, with chapter and verse and LOTS of tips. If you're looking to skim this monster instead, the good stuff is in the section from document page 49 - the section entitled Implications for Database Coders and in Annex B at the end: ARINC 424 Path Terminators which has lowdown and pictures on each of the 23 ARINC424 trackcodes.Everything a growing boy needs to melt his head with ARINC424 concepts and working practices! :D My apologies if you've already got these... but again, if I never mentioned them, and you didn't have them, well, that would be 'ouch!' ;)Cheers Terry - hope this is all of some use to you.Best Wishes,

[Guest staang]

Hi Neil,Write me at PlanePath@sw.rr.com so I can give you a link to cycle 0706 I just did for PSS. Then you can run it through the ringer.RegardsTerry

[Guest BigJacko]

>Hi Neil,>>Write me at PlanePath@sw.rr.com so I can give you a link to>cycle 0706 I just did for PSS. Then you can run it through the>ringer.>>Regards>TerryEmail sent, Terry - thank you! :)