Jump to content

Martin Loxbo

Members
  • Content Count

    221
  • Joined

  • Last visited

  • Days Won

    2

Martin Loxbo last won the day on May 28

Martin Loxbo had the most liked content!

Community Reputation

10 Good

Recent Profile Visitors

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

  1. There are plenty of ways to go about this but I think we'll stick to what we've be doing for the last 10+ years. I think it's well covered by the "procedural tower" provisions in the GRP and upcoming GCAP. What I take issue with is the terminology of using the word procedural to describe a service that may be based on radar or other surveillance means, as this is confusing. It would be more appropriate to call it something like "combined TWR/APP position" or "TWR position which provides a limited approach control service". It's worth noting that even IRL these units have restrictions on t
  2. I was just about to edit my message as well when I saw your reply, as I had a look in AIP Poland and they actually use ATC Surveillance Minimum Altitude. Let's not get too far into what can be seen on FR24 vs. what's an approved system used by ATC. But I can give you an example from Sweden: At Kiruna (ESNQ), it used to a be fully procedural airport as there is limited radar coverage in the area. ACC would hand over traffic with procedural separation descending to FL160 and Kiruna TWR would take over from there using procedural approach control (the MVA was FL100). A few years ago they installe
  3. Hi Mateusz, Based on the real life ICAO regs I agree with you (for example in Sweden all controllers at such positions have an ADI as well as APS rating IRL). But the VATSIM policy is not that detailed and I believe the intent here is to be able to give a realistic service at such positions without having to train the controllers up to full S3 level. This is also how we have operated these positions for over ten years without incident. Regarding MRVA, sorry for the generalisation, but my point was to avoid using the term "radar" in our terminology where "surveillance" would be mor
  4. The term "Procedural Tower" is misleading since it implies a procedural (i.e. non-radar) control position, when the definition according to the policy includes radar services. What the term actually describes is a combined position providing both aerodrome control (TWR) and approach control service (APP). We have many of these in Sweden at minor airports where a single controller is responsible for the TWR and APP service combined. Common to all of these is that they use radar (or other ATS surveillance means), so none are in fact procedural. When the GRP came into force we initially cons
  5. ... on the other hand I had contact with Sami, the UniATIS developer, a couple of months ago on the email listed. He started working on those issues Adrian mentioned, and I believe he fixed most of them. It might be worthwhile simply trying to contact him again.
  6. It's a good question, and something that used to bug me back in the day when I would fly something that really should have an APU/GPU but which wasn't simulated so the battery would die after a few minutes. To start with (no pun intended), that 2 minute battery life is probably not very realistic. On the other hand waiting for a clearance could be a lot longer than 2 minutes in many cases. While it may seem obvious that startup approval is all about starting engines, in Europe this approval is more connected to flight plan expiry and slot times. In real life, European ATC (there may be so
  7. Normally, for an IFR flight with no code assigned (IRL it would be in an area with no radar coverage, but on VATISM also applies when flying outside ATC coverage), you should squawk 2000. The code 2200 is an old "VATSIMism" - the pilot client would automatically switch from 1200 (which is the US VFR code that was set by default in some flight sims) to 2200 when a flight took off, as the 1200 VFR squawk meant the controller had no way to interact with the blip on the radar. What's odd about your flight is that apparently Sweden Control didn't give you a squawk code. Normally the first cont
  8. It sounds more likely that they said "identified", which is just another way of saying "radar contact", meaning they have verified that a certain radar blip with a certain squawk code is SAS527. You may be thinking of "squawk ident", which which means you should press the "Ident" button on the transponder (and reply by saying "squawk ident, SAS527"). This causes your blip on the controller's screen to be highlighted in a special way which is a way of distinguishing your radar blip from others. Note that you should only press the "Ident" button when asked to do so by ATC. On VATSIM I
  9. The TopSky plugin also has this functionality.
  10. Looks like I got it sort of backwards - your explanation makes more sense. Which means as of now there is no need for the workaround?
  11. That's probably the best explanation of 8.33 channels and frequency spacing that I've ever read. I can think of a few RW colleagues who could benefit from reading it. 😄 (The number of times you hear people surprised that they can hear the ATIS on 121.975 when the official channel is 121.980...!) To add to the confusion on VATSIM: It used to be that only 4 digits are transmitted over the network for each frequency (I assume this must have been changed since the bottleneck now is that some flight sims don't support 8.33 spacing?). The leading 1 was dropped and only the next 4 digits were ac
  12. What we usually do in the real world is to connect the route in the FMC so it more or less corresponds to the vectors you are being given. You can be creative if needed, like adding waypoints that are not in your original route, or even create your own waypoints. If you keep the programmed route updated to match the actual flown route, it means the FMC will give you accurate predictions for your VNAV path and distance to touchdown. If you don't want to press too many buttons in the FMC, you can simply extend the centerline. This gives you a clear indication of where the centerline is on y
  13. I found this on the airport website: http://www.ehamptonny.gov/DocumentCenter/View/2356/East-Hampton-Airport-Diagram-PDF?bidId=
  14. I'll repeat myself as well. 😉 Had another episode similar to the one above again this evening: When asked if the pilot filed as /v/ had voice, he says his mic is broken. "So you can hear me?" "Yes", and we continue as /r/. This, shall we call it, "erratic" text use seems to be more common with pilots who are new to the network. "Seasoned" /t/ or /r/ users usually know to file correctly and to clearly indicate their abilities to ATC. For example, it's a great help if a /r/ pilot includes "able to receive voice" or something along those lines in the initial text call, as it's sometimes
  15. Quick anecdote from this evening: - Flight filed as /v/ checks in using text. - I type "do you have voice?" - The pilot responds that unfortunately he does not. - I see his flight plan remarks says he's new to voice and might be shy to use it. - I reply that his flight plan says otherwise. 🙂 - The pilot responds that his mic is broken. - I ask if he can hear me. - He says he can. - We continue with /r/ 🤩 That's a lot of work just to figure out someone's voice/text status. Maybe the v/r/t status needs to be made more prominent to help pilots set the correct status for th
×
×
  • Create New...