Ervins Reinverts Posted July 31, 2010 at 09:32 AM Posted July 31, 2010 at 09:32 AM I am quite regularly facing two small issues, which, despite being small, are still annoying to some extent. One is about the NDBs as intersections (or at least, exactly one of them). I am mostly controlling in EVRR sector, and we get quite a few transit flights from St.Peterburg (ULLI) to Europe. And most of those depart ULLI through one of those NDB-intersections, namely Kotly (KO). For example this one from ULLI to LYTV that is going through my airspace as I write this: N0460F340 DCT KO B141 RANVA/N0460F340 UP863 GONOS UN619 SOKVA UL738 RUVAT UP870 BOKSU UM857 PODAN UZ200 TPS UM986 PUSTA/N0437F310 UL616 KEROP/N0449F350 UP192 TISAK UM173 VAL/N0445F340 UN732 POD DCT Euroscope does not seem to like that KO and instead of flightplan projection on radar screen, just shows a straight line to its destination with all the consequencies (RAM warning, missing COPN/COPX, etc). As soon as I remove the KO from the FPL, its all good, the rest of the flight plan is shown correctly and everything is in its place. I thought that maybe KO is not in the navdata and did a search through the active airway.txt but no - it is there. And then, as far as I can understand, it appears that ES is just ignoring entries it does not like. For example, if I change KO to KOTLY (and there is no such point in the navdata), that point itself is not shown (as expected), but all the rest of the FPL is shown correcly. So there seems to be some other thing. Any ideas? Maybe our Russian colleagues can comment on this if anyone is reading? I am wondering if this is issue only with KO or it is the same elsewhere too. Another thing is that I am allways getting those direction errors on UL738 from SOKVA to RUVAT. In all charts it can be seen that it is a two way airway. It is defined as such also in sector file - I turned on indication for it and the nearby one-way one so you see it here: Maybe there is error in FSNavigator data? I am not sure I am able to correctly decode its format to answer to this question. If there is anyone out there that is familiar with it, can you please check it? If its an error, we just have to live with it and hope it gets fixed with some AIRAC release. And just for clarification, the airways definitions in sector file are just for the display, like the one on the neighbouring airway, or direction info from sector files is also used by ES for FPL interpretation? Thanks in advance, Ervins EVRR FIR Ervins C1 controller EVRR & EETT FIR; BALT, EURN & EURE UIRs Follow EVRR_FIR on Twitter at http://twitter.com/evrr_fir Link to comment Share on other sites More sharing options...
Todor Atanasov 878664 Posted July 31, 2010 at 07:56 PM Posted July 31, 2010 at 07:56 PM I'm 99% sure ES don't read two letters fixs. So for it KO is simply a bug. As for the UL738 in the file I have for FSNavigator, the airway is one way only. ES uses that file to p[Mod - Happy Thoughts] the FP route. If a point is not found in it it checks the .sct file, but does not use the airway definition in it, only the fix/vor/ndb section. EuroScope BETA Tester/Board of Designers Link to comment Share on other sites More sharing options...
Gergely Csernak Posted August 10, 2010 at 11:15 AM Posted August 10, 2010 at 11:15 AM ES translates two (or even one) letter long names in the route section. There is no check for the length in the code. As it seems that KO causes problem while an invalid name is just ignored ES surely able to interpret KA as a point name and use it along the route. As the ROUTE interpretation is far from being exact there are some fixing tools in the code. One of them is to delete those points from the extracted route that are farer from the previous one than the twice of the distance of the whole route. It is used to ignore points that accidentally found on the other side of the Earth. I can imagine that there are more than one KA points in the FSNavigator database. And of some (knot really known) reason not the right one is selected, but the far away one. When the whole ROUTE section is deleted then these far away points are removed from the list. But they may cause deleting of other points as well. Normally if there are more than one points withe the same name the closer is selected. But I know there were some problems if this selection happened at the very beginning of the path. Like in your case as the first point just after departure. In this case if the airport itself is misspelled or not in the AIRPORT.TXT file (to get its coordinates) ES do not know which one is the closer (as no prior point) and may select the wrong one. Pleas, check your airport first. Gergely. EuroScope developer Link to comment Share on other sites More sharing options...
Recommended Posts