Jump to content

Tobias Dammers

  • Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by Tobias Dammers

  1. 20 hours ago, Andreas Fuchs said:

    You don't necessarily have to brief such an approach thoroughly, just have a look at the chart, check for significant differences (final approach altitude, minimum, missed approach procedure in general, navaids, final approach course) to the approach that you actually expected and briefed first.

    Yes, I was going to elaborate on that part, but decided to edit. You brief the alternative approach, but you can brush over the parts that are the same, and highlight only the differences (which is also why I said you should include in your briefing the steps needed to set up the aircraft for the other approach).

    • Like 1
  2. 7 hours ago, Dustin Rider said:

    Tobias, for those airports that have visual departure segments due to a lack of radar coverage, are those flown on an IFR clearance, or are you considered VFR until you reach the appropriate altitude and/or waypoint?

    "Visual" does not mean "VFR". The status of your flight is still IFR, throughout - just because you're IFR doesn't mean you cannot fly procedures with visual segments in them.

  3. Note btw. that this is a US thing; most European airport do not have radar vector SIDs. If you can't or don't want to fly an RNAV or conventional SID, you would just request a vectored departure, and receive detailed departure instructions, or, in some cases, you would depart visually, report a given altitude, and receive instructions from there. (The latter is usually the case where there is no radar coverage around the airport, like at EKVG or BIIS).

  4. Just file your flightplan as normally, but don't include and SID and STAR, and write "NO SID/STAR" in your REMARKS section. If all goes well, ATC will give you explicit departure instructions, and for the arrival, you'll probably get vectors.

    Heads up, though: for KDEN, vectored departures will most likely be given by assigning the "DENVER TWO" departure (found here: https://skyvector.com/files/tpp/2105/pdf/09077DENVER.PDF) - but that's basically just "vectors", with a couple additional instructions, and you don't need an FMC to fly that one.

  5. It depends. In principle, yes, you can always ask for vectors (not "vectors to the STAR" though - just request "vectors").

    However, especially during busy events, this puts an extra burden on the controller, so be aware of that - they can't deny you service (that would be against VATSIM policy), but they may be forced to delay you in order to fit you into the flow in a manageable way. Also expect questions as to why.

    Now, the most likely reason why the FMC won't give you the procedures ATC told you to fly would be that your FMC data is outdated. VATSIM generally follows real-world procedures where possible, and those are updated every 4 weeks (these versions are called "AIRAC Cycles", identified by a four-digit number consisting of the two digits of the year and the cycle number within that year, e.g., AIRAC 2012 is the 12th AIRAC cycle of the year 2020), but most sims do not update their data all the time, so unless you can get your data from elsewhere, your FMC data is most likely not up to date. The most popular solution to this by far is Navigraph, who, for a fee, provide up-to-date FMC data and charts in a myriad of formats.

    If you can't or don't want to spend money on that data, the next best thing would be to figure out which AIRAC cycle you have in your FMC, and mention that in your remarks. Also, as part of your preflight, compare your FMC data against up-to-date charts (e.g. from skyvector, or from the relevant real-world AIP), and take note of differences. Often, procedure updates between AIRAC cycles are very minor, and might not even affect the flight path at all, but they still get a new designator. For example, obstacle information on the chart may be updated - but this does not affect how your FMC flies it, it's just something to be aware of when flying. Speed restrictions are another thing that you can mostly ignore, you just have to make sure to honor the updated speeds. In such cases, you can just program the old designator in case ATC gives you the newer one - but you really need to brief these things beforehand, because there is no way you can safely do this kind of thing in flight while also flying the aircraft and keeping up with ATC. If there is no procedure with the same flight path, you can also request the older procedure explicitly; often, ATC can accommodate those and will grant your request, and then you can just fly whatever you have. If all that fails, you can still resort to requesting vectors.

    Another alternative would be to simply file "no SID/STAR". This way, many controllers will just give you vectors to final or detailed departure instructions straight away.

    1. Technology wise, yes, sure, there's text chat built into the VATSIM network protocol and all clients. Voice messages are not automatically converted into text though, and they aren't logged either, so it wouldn't be a "copy", it would be the ATC manually repeating their instruction in text. Needless to say, this is not something that's normally done, but in some situations, using text chat is a reasonable way out when voice communication fails. Some controllers will also use text chat in lieu of CPDLC/ACARS, particularly for PDC (pre-departure clearance). In principle, you can also use text for all communications; if you want to do that, put "/t/" in your remarks. Keep in mind though that most people on the network would prefer to see voice communications wherever possible - it's easier for everyone, and makes for better immersion.
    2. Sorry, can't help you with that one since I don't use MSFS.
    3. That is sort of OK in principle, but not really a solution - after all, you can also get re-routings in flight, and at least when flying in Europe, your arrival runway, approach, and STAR/Transition will only be assigned as you approach your last enroute waypoint, so being able to modify your flight plan on the fly (pun intended) is kind of critical. Unfortunately, it seems that the default aircraft in MSFS2020 can't do that, so the standing recommendation is to either buy an add-on aircraft that can do it, or use a different sim, or fly flight plans and aircraft types that don't require an FMS.
  6. Just now, Robert Shearman Jr said:

    ... as long as you did one of those things by mistake and not in deliberate, willful disregard of a controller's instruction. 

    ...which would be a violation of COC B8, so.

    • Like 1
  7. 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.

  8. 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).

  9. 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.

  10. 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.

  11. 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.

  12. 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.

  13. 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.

  14. 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.

  15. 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.
  16. 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".
  17. 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
  18. 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.

  19. 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.

  20. 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.

  • Create New...