Jump to content

Rob Killins 897126

Members
  • Content Count

    114
  • Joined

  • Last visited

    Never

Community Reputation

0 Neutral

1 Follower

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I am finding that my Euroscope setup isn't representing some pilot's (mostly overseas) flight plans "accurately". For example, see the series of screen shots attached showing an AAL flight that p[Mod - Happy Thoughts]ed through my airspace (CZWG) of a flight from ZBAA to KORD. The route is filed correctly: YV B334 TGO G212 HRB A588 SIMLI G494 BLG A803 OSKON A218 LISKI NCA80 ADREW NCA23 YSF NCA22 YTH J542 YWG J89 DLH SHIKY FYTTE2 However, the waypoint depiction seems to end prematurely at some point along A218. There doesn't appear to be any representation beyond a point in A218. (see
  2. Thanks folks for your support. Kirk, thanks for sharing the wiki that I am quite familiar with. Appreciate I am having difficulty applying the explanation to my particular situation. I think where I was going with in my original post is how do I handle "the route will be declared by any FIX, VOR or NDB that makes part of the routing with spaces between each route element." when there is no fix, VOR or NDB making up a route, as in the case of the two examples I gave. It could just be I am not reading the SID properly and with a better understanding, would have no problem applying the logic.
  3. Thanks Gergely, replies and support is always appreciated (although I hate taking you away from ongoing development of a great product to help resolve simple problems.) I'm not quite sure I understand how everything works. The uniatis url provides an external ATIS updating service correct? It Iuse this service, is it which provides the format of the script? And if so, how is the script changed? I can opt not to use an updating service like uniatis, but them I miss the luxury of automated updating. I would have to rebuild the script after each ATIS change? I can see that with this optio
  4. I have either omitted, or improperly coded SID [Mod - Happy Thoughts]ignments in my ESE in most part to misinterpretation of purpose and how to apply my local airport's only SID to Euroscope. Here is a symptom I'm experienced that may or may not be related to my misinterpretation and bad coding for CYWG (Winnipeg). When I [Mod - Happy Thoughts]ign a departing aircraft its departure runway and SID, the pilot's FP will populate with the proper route with the SID (ARKAY1/13) preceding his route. Everything looks right, however, the waypoint listing is way messed up! It will list the SID but w
  5. I am trying to work out some problems with having Euroscope's Voice ATIS setup dialogue do what I need it to do. I have entered the ATIS airport: CYQR. I am able to successfully pull up the METAR. The ATIS maker URL i: http://uniatis.net/atis.php?arr=$arrrwy($atisairport)&dep=$deprwy($atisairport)&apptype=ILS&info=$atiscode&metar=$metar($atisairport) (if I understand correctly this cannot be customized?) With a press of the [Test URL] button, the text ATIS and multiple record ATIS script populates properly. For example: [information]G[weather at]2300Z[,][Win
  6. Thank you David, that was very helpful. Would I use 5? Or -5?
  7. The instructions for defining the sector magnetic variation I find a bit vague based on the information I have. (VRC docs) Referring to my airport charts, information referencing variation indicate a 5 degree E variation in 2003, with an annual rate of change of 8' west. What value would I enter in line 8 of the INFO section to best reflect the magnetic variation?
  8. I will indeed give that a try Gergely. We're already maxed out with 4 vis points for that sector, so adding more isn't an option.
  9. Thank you Gergely for your input into this scenario. If I'm understanding you correct, your stating that the issue stems around a server limitation rather than a Euroscope issue, and that the supporting .ese files are not likely the culprit. Not being one to understand the complexities of how the servers work, I'm curious as to why our one position wouldn't be recognized, and what steps would be needed to have it recognized (if it's even possible). VATRUS I would imagine covers a lot of far north airspace ... does anyone know if they experience similar problems? Other than perhaps test
  10. Hi folks, Just an update to anyone that may be following this. I spent considerable time yesterday combing meticulously through both ese files looking for an ellusive typo which may be the culprit for this issue. As Mr. Frias had mentioned, it's a dizzying task with all the "y"s and "z"s. I was unable to find any issue in the ZEG ese, but I made a few changes to it's neighbouring ZWG ese. I added the inverse sector line relationships as Miguel suggested in an earlier posts, and also found sector ownership priority errors. I had originally had zeg_ac_ctr (in the ZWG file) OWNER: EG
  11. Some great insight Miguel. I'm at a loss as to what to do at this point. CZEG FIR extends from the 49th parallel north to the north pole. The difference in magnetic variation between the south and the north would be hard to define with only one value. For example, Inuvik NT (far north) has a magnetic variation of 31East, whereas Calgary in the south of the FIR has a published variation of 17East. The value in the sector file is -6. But, why does everything appear to work properly when it's just the one wide sector ... it covers the same area as the problem subsector? [INFO] CZEG_FIR
  12. Hi Miguel, I feel like a pest with this nagging problem, but do appreciate your ongoing help. Magnetic variation? That is set up in the [iNFO] module of the .sct2 file correct? How can I go about determining whether or not the value I have is correct? I never gave it any thought as to where the value is gathered from, so it could be way off. Our latest sector rewrite included a redefinition of radio/visibility points in order to optimize coverage. Again, not sure what to look for in terms of being correct or incorrect. The progression of sector development over the past couple year
  13. Hi Miguel, thank you for your continued support. We tested additionally with your recommendation by adding the second line to the Sectorline definition without any success. There is an initial connection, but within a few minutes it is dropped. As mentioned, we do not have any issues with similar neighbouring subsectors, nor do we have any issue when its simply CZEG_CTR and CZWG_CTR connected as wide centres. CZEG is a large FIR stretching to the far north of the globe. Could geography or ES's map projection be limiting it? I doubt it, as if it did, the wide sector relationship wou
  14. Hi Folks, So ... with some further testing, we have been able now to see each other. The sectorline "illuminates" accordingly with both sectors (CZEG_AC_CTR and CZWG_CTR) online, but within 3 or 4 minutes, my neighbour's callsign turns white in the controller list, and within seconds, the connection is lost. He has not voluntarily selected to logoff. This is a neighbouring smaller sector within the FIR (CZEG). The other neighbouring subsectors do not behave like this. Miguel ... does this still suggest an issue with the sector/sectorline definitions in the ese? What should I consider l
  15. Thanks Miguel, I was really hoping that was the solution. The frequencies in both sector files match.
×
×
  • Create New...