dz111 11 Posted January 9, 2014 Share Posted January 9, 2014 PFPX Version 1.12 OS: Windows 7 64-bit Severity: Medium When planning a flight from VHHH/HKG to PANC/ANC that traverses Chinese Metric RVSM airspace, PFPX planned at Standard Level 9500m and Standard Level 9800m. According to the Chinese CAA (http://www.chinarma.cn/English/flightlevelallocationscheme.html) these are equivalent to FL311 and FL321, respectively. However, in the Flight Level Profile field and Navigation Log, these are listed as FL312 and FL322. Using a conversion factor of 3.28 ft per m, these levels are in fact correct to the nearest 100 feet. However, the requirement of the airspace is to operate using the table from the Chinese CAA. Steps to reproduce: Plan a flight at Standard Level 9500m or Standard Level 9800m (this bug probably also occurs for other levels too). Link to comment Share on other sites More sharing options...
dougsnow 50 Posted January 9, 2014 Share Posted January 9, 2014 thats a navdata issue, as they set the acceptable flight levels in the FIR Data Link to comment Share on other sites More sharing options...
dz111 11 Posted January 9, 2014 Author Share Posted January 9, 2014 My understanding is that the navdata stores a "cruise table" code rather than the actual accepted levels. Is that incorrect? A separate, but possibly related issue is that when submitting to VATSIM, the cruising level field is filled in with the exact altitude (e.g. 9500m -> 31168ft). I would suggest that it would make more sense for this be rounded. Link to comment Share on other sites More sharing options...
CaptainTim 11 Posted January 9, 2014 Share Posted January 9, 2014 David, Which NavData cycle are you currently using? Aerosoft or Navigraph? Cheers, Tim Link to comment Share on other sites More sharing options...
dz111 11 Posted January 10, 2014 Author Share Posted January 10, 2014 Navigraph 1313. I'll retry this when I stop being lazy and get 1401 (although their new manager program looks interesting). I'll also see if I know anyone with an Aerosoft database who might be able to try this. Link to comment Share on other sites More sharing options...
CaptainTim 11 Posted January 11, 2014 Share Posted January 11, 2014 Hi David, Just planned a flight from VHHH to PANC off the bat as I use Aerosoft Data 1401. Navlog's giving me an initial of FL351 and on the ATC plan it says K0910S1070 Is that what your after? It changes to FL350 once required. Cheers, Tim Link to comment Share on other sites More sharing options...
dz111 11 Posted January 11, 2014 Author Share Posted January 11, 2014 10700m * 3.28 = 35096ft ~ 35100ft, which gives the correct answer regardless of whether rounding is used or a lookup table. For sure, 9500m converted to feet and rounded using normal rules gives 31200ft. However, according to the Chinese CAA, aircraft using altimeters that read in feet should operate at 31100ft. I have now tried with Navigraph 1401 - same thing happens. Link to comment Share on other sites More sharing options...
CaptainTim 11 Posted January 11, 2014 Share Posted January 11, 2014 10700m * 3.28 = 35096ft ~ 35100ft, which gives the correct answer regardless of whether rounding is used or a lookup table. For sure, 9500m converted to feet and rounded using normal rules gives 31200ft. However, according to the Chinese CAA, aircraft using altimeters that read in feet should operate at 31100ft. I have now tried with Navigraph 1401 - same thing happens. David, Just done this now and for me it's the same. It says 9500 in the ATC Plan and Nav Log it says FL312. Perhaps not just isolated too navigraph? Cheers, Tim Link to comment Share on other sites More sharing options...
dz111 11 Posted January 12, 2014 Author Share Posted January 12, 2014 What I suspect is that the navdata stores a "cruise table" code (see the "Details" tab of the route editor, last column) and PFPX stores the definition of these "cruise tables" in it's internal data files. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.