Jump to content

Tobias Dammers

Members
  • Content Count

    247
  • Joined

  • Last visited

  • Days Won

    6

Posts posted by Tobias Dammers

  1. IRL, "pilot deviation" means that a pilot has deviated from mandatory procedures, or otherwise violated the rules, and there will be some aftermath to this - paperwork, investigation, questioning, and possibly disciplinary action, depending on the findings.

    We don't do any of that aftermath on VATSIM, so if an ATCO says "pilot deviation", then that's just a way of saying that you did something wrong that would have serious consequences IRL, like turning the wrong way, landing on the wrong runway, busting your altitude clearance, flying VFR into controlled airspace without clearance, flying past your clearance limit, etc. etc., but on VATSIM, there are no consequences. The only things that can get you disciplined are violations of the Code Of Conduct and similar rules, and it's not controllers who get to police those, only supervisors can do that.

  2. Also note that at many European airports, the GA apron is uncontrolled, which means that you can start your engine, pushback, and taxi on the apron, at your own discretion (but you are also responsible for making sure you're not causing any problems by doing so). So you'd start your engines as needed, call Delivery for your IFR clearance, and then just pushback and taxi as needed, and call up Ground (or Tower, as the case may be) when you reach the limit of the uncontrolled apron (usually a designated apron exit point).

  3. 7 hours ago, Alistair Thomson said:

    we're not talking about being 3 degrees high at 3000 ft (hopefully)!

    Indeed - being 3 degrees high at 3000 means you'd be on a 6° angle from the runway, which means that you're at a point where you should be down to 1496 ft on the correct glideslope. At this point, you're 4.7 miles out, which means you have passed the outer marker a good while ago, and that alone should have been a red flag. If the visibility isn't lousy, you should also have the field in sight by now, and it should look weird, because you're looking at it from way too high.

  4. Capturing from above is somewhat problematic for another reason.

    If you capture from below, then you will be in level flight, or in a stable shallow descent; capturing the glideslope, then, will have you nose down, which will temporarily increase your airspeed, and the autothrottle then reacts by gently retarding to bring you back to your selected approach speed. By contrast, if you capture from above, you will also be in a stable descent, but at a fairly steep angle, so probably at a low power setting (if not idle), and when you capture the glideslope, the autopilot will pull up. Your airspeed temporarily decreases, and the autothrottle will counter this by advancing - but it takes a while for this to happen, and then a bit more for the fans to spin up, and during that time, you are flying slower than you should be. Now if you remember that airspeed is life insurance, it should be immediately obvious that capturing from below is much safer.

    And another reason: you're in a critical, fairly high-workload flight phase, during which a lot of things can go wrong. Now consider what happens when, for whichever reason (technical, human, doesn't matter), you fail to capture the glideslope. If you're capturing from below, then the default response, doing nothing, results in a relatively safe level overflight of the airfield along the extended runway centerline. Not ideal, and you probably want to tell ATC about it ASAP, but you have plenty of time to live and figure out how to deal with it. If you're capturing from above, then you are in a steep descent that intersects this frightful thing known as "the ground", and the do-nothing default will get you down a bit sooner than you had hoped. Say you're descending 2000 fpm, and you miss your 2000 ft AGL glideslope capture - you now have 1 minute (less if the terrain isn't flat and free of obstacles) to realize that something went wrong, and correctly deal with the problem. Both can be done of course, but I know what I'd prefer.

  5. 18 hours ago, Kyle Sanders said:

    Does anyone know of any current project that is being worked on for a Land Line communication system that is of good quality and has serious traction to being complete within 12 months from this post?

    There are several working solutions to this problem already, all reasonably close to what you might want.

    TeamSpeak seems popular; Discord would work; there's Mumble, if you want something open source.

    I think the problem is a social one more than a technical one - getting everyone to agree on a single communication channel for this stuff. I don't think writing yet another VoIP-ish solution for this would help.

  6. The physics simulation algorithm is not actually all that relevant. There is no reason why you couldn't perform two or three updates of that Blade Element algorithm for each rendered frame - even a complex simulation like this is usually limited on rendering, not physics, which means that frame skipping would be a perfectly viable way of sacrificing perceived performance (number of frames shown per second) for correctness (accuracy and stability of physics simulation).

    Yes, XP11's physics simulation relies on the time step delta to be small enough, but the same also applies to literally every other viable integrator - aerodynamics are way way way too complex to boil it all down into a continuous-time formula that you can just interpolate without introducing any errors. And then we haven't even started to consider floating-point errors, which is yet another can of worms.

    The real reason why they do it this way is because they chose to run physics and rendering in strict lock-step: exactly one physics update per screen update, no exceptions. There is a lot to say for this approach, especially with a physics engine that allows for variable time delta: it makes things a lot simpler, and it avoids jitter due to interference effects between the screen update rate and the logic update rate (e.g.: if you run the logic at 60 fps and the renderer does 59 fps, then there will be one frame skip per second, and that frame skip will amount to approx. 1/60th second of sim time; this is going to be noticeable as a tiny little jump at a regular 1-second interval). Strict lock-step with variable delta takes care of that: each frame receives a world state that matches the simulated time *exactly*, down to the limits of what the computer can represent. But still, variable or not, the delta cannot become too large, so when render frame rate drops below a certain critical value, the time delta will exceed the critical value, and the numeric calculations become unstable. And in order to keep things simple, what they did is they simply put a hard limit on the time delta: whenever the renderer takes longer than 50 milliseconds, the time delta is capped to 50 ms, and thus the simulation is no longer advanced in real time, but in steps of 50 ms per rendered frame. So if you're doing 10 fps, then you get 10 x 50ms = 0.5s of sim time per 1s of wall-clock time: you're running the sim at half the rate.

    Other sims adopt a different approach: they run the renderer at whatever rate it can achieve, and then do as many physics updates as needed to catch up. I'm not sure how FSX does it, but at least for FlightGear, I know that the FDM runs at a constant 120 fps; if the renderer runs at 60 fps, then the FDM runs twice per frame, at 20 fps it'll run 6 FDM updates per frame, and you can go all the way down to 1 fps, literally a slideshow, and the FDM just updates 120 times per frame.

    Oh, and the "tables vs. blade physics" thing is largely irrelevant, because the problem is not how you come up with forces and moments, but how you get from forces and moments at a discrete point in time to a good approximation of their continuous-time dynamics - in other words, approximating continuous-domain integrals using discrete-time sums. A more sophisticated physics algorithms is less dependant on a good integrator, but the fundamental problem, and viable solutions, remain.

  7. 1 hour ago, Alistair Thomson said:

    I'm wondering if there might be value in considering changing that?

    This comes up every now and then, and AFAICT, the bottom line is always that the benefit (enforcing a certain quality standard among pilots) is not worth the cost (losing as large portion of the pilot population, many of them for good).

    It's different for controllers: right now, pilots outnumber controllers roughly 10:1, and that's a decent ratio. Imagine what happens when that ratio shifts to something like 2:1, or even 1:1. It gets silly fast, and no amount of pilot competence can make up for that. If you only ever get to control 1 or 2 aircraft at once, then there's not much to it anymore, is there. And if you're flying and never get anywhere near anyone else, and all your ATC communication boils down to "climb to cruise, proceed direct IAF, when ready descend your discretion", you might as well fly offline.

  8. Not to mention that pilot ratings, unlike controller ratings, are purely decorative; they don't "unlock" anything on VATSIM, except training courses for higher ratings. Anything you can do as a pilot, outside of the training system, can be done with a P0 rating, and I believe there are no plans of changing this either.

  9. The problem isn't FPS itself, but the fact that XP11 (unlike all the other sims) will slow down simulation rate when FPS drops below 20.

    VATSIM doesn't really care if you're seeing a slideshow on your end; what we do care about is that when you report 240 knots, you will cover roughly 4 miles per minute - but XP11 running at 10 fps will slow down sim time by 50%, so your airspeed indicator will still show 240 knots, while you're really moving at 120 knots, 2 miles per minute.

    Now, that hardware isn't exactly top notch; but it being a laptop, just buying, say, a used GTX1050Ti is not really an option. This leaves you with:

    • Flying (much) simpler aircraft models. A 737 is very common, but it's still an airliner, and as such, it has complex systems and instruments that need to be simulated. Maybe try a simple steam-gauge light aircraft, like a Cessna or a PA-28, and see if that helps any.
    • Rule out other applications eating into your system resources.
    • See if you can obtain a copy of FSX, or try FlightGear. You won't see significantly better performance, possibly even worse, but unlike XP11, these sims don't dilate time to keep up.
  10. My recommendations would be:

    • Aim to do full flights. Once you're in the air and TWR has handed you off, the worst is behind you, might as well keep flying.
    • Disconnecting is 100% fine at any point, people do it for all sorts of reasons, and controllers will prefer that over getting in over your head and messing things up for everyone.
    • Reconnecting is also allowed, but it's considered good etiquette to try and minimize the disruption. I'd reconnect well before my top-of-descent, to give ATC a fighting chance of working me in gracefully.
    • A useful trick when reconnecting is to connect as observer first; this gives you a chance of assessing the situation from within before connecting "for real".
  11. I think at this point it's a good idea to clarify the difference between FREQUENCIES and CHANNELS, and why 8.33 spacing makes it all such a terrible mess.

    In the old 25 kHz days, things were simple. You had channels spaced 25 kHz apart, and you would refer to them by their exact frequency. 118.00, 118.025, 118.050, 118.075. Easy peasy.

    But with the frequency space getting ever more crowded, and the precision of radio equipment improving, a new standard was devised that packs more channels into the same frequency space: "8.33 kHz channel spacing". The idea is simple: just put 3 times as many frequencies into the same space, such that there are two extra channels between each pair of 25 kHz channels. The distance between those new channels is now 8⅓ kHz, rounded to 8.33. So we getfrequencies like these: 118.000, 118.008333333...., 118.0166666666666..., 118.025, 118.03333333333...., 118.04166666666..., 118.050, etc. That's kind of awkward though, for two reasons: first, some of these have infinitely long decimal expansions; and second, those that don't look like 25 kHz channels. The latter bit matters because radio equipment configured for 25kHz channels will transmit and receive on a wider spectrum, so while the frequency may be the same, we still want to make sure that the radio equipment is configured for the narrower 8.33 frequency bands when we're transmitting or listening on an 8.33 channel. In a nutshell, if you tune a 25 kHz radio to 118.025, you will hear transmissions made from 25 kHz radios on 118.025, but you will also hear transmissions from 8.33 radio equipment on channel 118.030 (which uses the same 118.025 frequency, but over a narrower range), as well as 8.33 transmissions on the adjacent channels, 118.015 (actual frequency 118.0166666...) and 118.035 (actual frequency 118.0333333...), because your 25 kHz radio listens to the entire frequency range roughly from 118.0125 to 118.0375.

    These problems are solved by rounding the awkward infinite expansions to the nearest 5 kHz, and adding 5 kHz to each frequency that aligns with a 25 kHz channel to distinguish the spacings. So in 8.33 spacing, the frequency 118.000 is reported as 118.005, 118.0083333333... becomes 118.010, 118.016666666... becomes 118.015, 118.025 becomes 118.030, and so on. And now if you dial 118.025, the radio equipment recognizes this as a 25 kHz channel, and listens on 118.025 +/- 0.0125; but if you dial 118.030, it listens on 118.025 +/- 0.004166666...

    In other news, the number you dial into an 8.33-capable radio is no longer the actual frequency; it is a made-up number that references a 25 kHz or 8.33 kHz channel, and the radio equipment automatically maps that to the right frequency.

    Note further some interesting consequences of this:

    • Some possible inputs are not used at all. For example, 118.020 is not a thing, the nearest channels are 118.015 (118.016666... @8.33), 118.025 (118.025 @25), and 118.030 (118.025 @8.33)
    • Some frequencies are covered by more than one channel: 118.025 and 118.030 both map to 118.025 MHz, but with different spacings.

    See this page for some more in-depth explanations and a handy conversion table.

    Unfortunately, the distinction between channel (what you enter into your radio, and what is displayed) and frequency (what you're actually transmitting on) isn't always made clear, and to add insult to injury, some VATSIM clients / sims are still incapable of using 8.33 frequencies. The combination of these two leads to the terrible mess we're seeing.

    For practical day-to-day usage, the workaround is this:

    • Limit frequencies / channels used on the network to the frequencies used for 25 kHz channels (e.g. 118.025)
    • In airspaces that use 8.33 spacing IRL, report the corresponding 8.33 channel, not the frequency (e.g. 118.030)
    • Remember that things are borked, and accept the fact that this may cause a deviation by 0.005 either way on either end. So when you're told to contact 118.030, and that doesn't work, try 118.025 instead.

    Ultimately, what we should have is a proper implementation of how things work - I would suggest using actual frequencies on the network, ignoring the bandwidth difference (which is not an issue since we're not dealing with actual radio frequencies, and we don't have to separate them out on the receiving end), and leaving the conversion to and from channels to the pilot clients and/or sims.

    • Like 5
  12. I don't have any inside information for you, but in general, I don't think adding fields to a JSON data structure would require upgrading a version number - after all, your code should still work unchanged, and just ignore those extra fields. That's how JSON-consuming code is usually written. It might not be a great idea to *depend* on those fields until the documentation explicitly mentions them, but you can surely *ignore* them.

  13. VATSIM's infrastructure doesn't currently support Y (begin IFR, switch to VFR) or Z (the other way around) flight plans.

    To fly a Y flight plan, file as IFR, and put "VFR" in your route at the point where you intend to transition.

  14. On 4/2/2021 at 1:17 PM, Koen Meier said:

    It is more that pilots don’t really read the airport information charts telling about the procedures for tailwind components. You won’t solve it with having atis available I feel. Generally an atis means that a controller is also active. 

    FWIW, even if you make it as easy as EHAM, people STILL use all the wrong runways.

  15. 55 minutes ago, Robert Shearman Jr said:

    Most often, it happens when the wind changes direction but remains less than 10kt, but the real world airport stays in the tailwind configuration because flipping the airspace is so much more difficult than doing it on VATSIM with a much lower level of traffic saturation.  On VATSIM I'm gonna go ahead and run the configuration aligned with the wind.

    Plus IRL it's safe to assume that pilots are competent enough to judge whether the tailwind is within limits, and if so, perform a perfectly safe tailwind landing. Whereas on VATSIM, ...

    • Like 1
  16. 9 hours ago, Joe Connolly said:

    So, I was out of LAX on DOTSS2 which takes you west a ways then left turn to come back around east. I got barked at by ATC for making that turn- I didn't debate over the comm but I was flying a procedure, was I supposed to get permission to turn?

    It all hinges on what you were cleared for. As a general rule, fly the clearance, not the plan.

    If your IFR clearance says something like "ABC123, you are cleared to destination KABC via the DOTSS2 departure, then as filed, initial climb 5000 feet, expect flight level 240 after 10 minutes, squawk 1234", then they want you to fly the SID. If however it says something like "ABC123, you are cleared to destination KABC, after departure maintain runway heading, climb 5000 feet, expect flight level 240 after 10 minutes, squawk 1234", then you are not cleared to fly the departure as published, but expected to maintain runway heading until further notice. I may have gotten the clearance phraseology mildly wrong, as I don't fly in the US a lot, but the gist is that unless you were explicitly cleared for a procedure, you can't just fly it.

    • Like 1
  17. These two airports have had large-scale overhauls of their arrival procedures in recent AIRACs. The procedures that used to be called "transitions" are now published as "GPS/RNAV ARRIVAL CHART / TRANSITION TO FINAL APPROACH (OVERLAY TO STANDARD RADAR VECTORING PATTERN)", like this one: https://aip.dfs.de/basicIFR/scripts/getPage.php?part=AD&id=40749FD23E58E92F12F6F945F20D7399&title=AD 2 EDDM 3-1-1

    I don't know why they're not on vatsim-germany, but DFS publishes them, and you should be able to find your way from https://aip.dfs.de/basicIFR/ to find whichever charts you need.

  18. On 3/3/2021 at 8:21 PM, Gareth Myers said:

    - Do I tell an ATC controller what approach I want?

    You can request a specific approach, but this isn't mandatory, and if you're flying a relatively standard airliner, ATC will give you the most appropriate approach they can.

    As an example, when I fly the Embraer Lineage 1000 (a bizjet conversion of the E190), I generally want to park near the GAT, and at some airports, this means I would benefit from landing on a different runway than the airliners - e.g., at EHAM, I generally prefer runway 04/22, because I can taxi right off onto the GA apron, and skip the lengthy taxi. So when I fly into EHAM, I'll usually request that runway proactively and early, if I get a chance.

    On 3/3/2021 at 8:21 PM, Gareth Myers said:

    - Or will I be told the approach I'm doing by the controller?

    This is the normal procedure: ATC tells you which approach to fly, and you accept it and fly it. However, it is *your* responsibility to check whether the approach is within the limits of you as a pilot and your aircraft, and to reject the clearance if you aren't convinced that you can fly the approach. If you're too heavy for that shorter runway, by all means say so. If you're not comfortable flying that complex visual procedure into an airport you've never seen before, request an ILS approach. If ATC gives you a last-minute change, feel free to reject it due to workload.

    On 3/3/2021 at 8:21 PM, Gareth Myers said:

    - Will I need to add this approach to the MCDU mid-flight?

    Technically no, but you do need to be prepared to fly whichever approach is given. Even for a 30-minute hop, it's impossible to tell for sure which approach you will be given beforehand. Frankly, if you're flying one of those aircraft where you can't change your route mid-flight, then I'd recommend not taking those onto VATSIM. It's not just approaches; you may also be given directs (quite common), reroutings (not common, but happens), holds (not very common, but sometimes you get "lucky"), detours, etc.; and you kind of want to be able to tell your FMS how to fly those.

  19. Oh boy... yes, now that I think about it, that does make sense, after all an aircraft is a big metal tube...

    Though technically the signal doesn't get interrupted, "only" disturbed, so the NAV equipment will still pick up *something*, it will just be a bit wrong.

  20. 18 hours ago, Marc Sieffert said:

    On the holding on May (same chart below) I see the info D1,5 ... This means holding with 1,5 minute I assume, right?

    No. "D1.5" means "1.5 DME", and defines the point in the MAY holding where you have to turn left in order to leave the holding; it has absolutely nothing to do with the TIMBA holding.

    The TIMBA holding is a standard right-hand holding pattern, which means the straight legs are standard 1-minute legs.

  21. 10 hours ago, Ethan Bleeker said:

    SFO is a class B airport, so in real life, I would first contact clearance delivery before contacting ground for taxi clearance. There's currently no clearance controller, or anyone above that level, online. Does that mean I should just skip that step and jump right to requesting taxi clearance from ground? Would the ground controller give me a squawk code and altitude for exiting the Bravo?

    Ground is above delivery, so that's who you would contact. Top-down goes DEL -> GND -> TWR -> APP/DEP -> CTR. (There are sometimes additional positions in between, and above, but you don't normally have to worry about those). GND is above DEL, so the ground controller will also cover DEL when no DEL controller is online.

    10 hours ago, Ethan Bleeker said:

    KLAX currently only has a ground controller online. However, it is covered by LA center. Does that mean the center controller would be providing approach / tower services? According to the "top-down" model, they should be, but it's unrealistic to expect they'd be controlling every airport in LA center. Is this something I could verify by checking the controller's info on vPilot? If not, are there other steps I should take?

    It may look like a lot, but that's exactly how it works - when GND is the highest staffed position at an airport, then the CTR controller covering the area will provide TWR and APP/DEP for that airport. And in fact, if no position at the airport is staffed at all, CTR will cover all of them, at least if it's a towered airport. In theory, this could lead to a gargantuan workload for that controller, but in practice it's not usually that bad, because 1) when there aren't a lot of controllers online, there will also be relatively few pilots, so the overall amount traffic should be manageable, and 2) if it gets too busy, the controller is always free to step down to a lower position in the stack, leaving CTR to Unicom. That's because all controllers are qualified to staff any position up to the maximum one their rating allows (this is also necessary to provide top-down control), so if a controller logs on to LA Center and finds themselves overwhelmed with hundreds of pilots in their airspace, they may choose to round things up and "downgrade" to, say, SFO Approach. This is not something you need to worry about, and controllers, especially those experienced enough to staff CTR positions, are pretty good at managing their workload.

    Besides checking top-down coverage, there isn't much you need to do either. Essentially, there are only three possible situations:

    1. You have just spawned at an airport and want to depart. Find out whether anyone is covering DEL at the airport (either top-down or directly) and contact them.
    2. You are currently talking to someone. You don't need to worry about anything, they will tell you who to contact, on which frequency, and when. If a controller is available for the next phase of your flight, they will hand you over; if not, they will tell you to "monitor Unicom 122.8".
    3. You have commenced your flight under Unicom, and you are approaching controlled airspace. This is the only situation where you need to pay a bit of attention, because it is your responsibility to make sure you are talking to ATC when there is service. The things to watch for here are FIR boundaries (which you can get from enroute charts), telling you when you might need to contact a CTR controller, and your destination. If you're flying into a CTR controller's airspace, aim to contact them a couple minutes before entry, though they will often send you a Contact-Me message before that point. If you're flying towards your destination and APP is staffed, contact them during your descent, or as you enter the STAR, but definitely a good while before reaching your clearance limit. If only TWR is staffed, contact them when established; if only GND is staffed, contact them as you vacate the runway; if only DEL is staffed, don't contact them at all, because you're arriving, not departing. And of course once you're talking to any of these positions, scenario 2 kicks in, and they will tell you who to talk to next.
    10 hours ago, Ethan Bleeker said:

    On the other hand, let's say I were departing from KLAX. Would I get my takeoff clearance from LA center since there's no tower controller online?

    Yes. LA Center provides top-down service all the way down to DEL for any airport in their area that isn't staffed.

    • Like 1
  22. Took a quick look at the parking / docking chart, but there doesn't seem to be any stand from which you could do a taxi-out, they're all nose-in, except for the GA/Business aprons, which don't have any precisely designated parking areas.

    The airport briefing says this on the matter of taxi-out / power-back:

    Quote

    Aircraft will not be permitted to reverse off pier-served stands under their own power. Aircraft may be permitted to reverse off remote stands at the discretion of the aerodrome authority. Permission must be obtained from the Airfield Duty Manager (Ext. 3331) via ATC prior to manoeuvre.

    (Source: https://www.aurora.nats.co.uk/htmlAIP/Publications/2021-01-28-AIRAC/html/eAIP/EG-AD-2.EGCC-en-GB.html#AD-2.EGCC)

    I don't know how it's normally done at EGCC, but I would expect that if you're on a regular stand, you would normally be cleared for pushback, unless you are at a remote stand (like those North of taxiway Z) and explicitly request a power-back. GA aprons are often "push/taxi at pilot's discretion", not controlled, so you would request startup, and be advised to hold short and report somewhere on the boundary of GND's area of responsibility.

×
×
  • Create New...