skelsey

On the subject of Colgan... Perhaps we can now all agree that the FAA nonsense of requiring pilots to blat around in GA and regional carriers for 1500 hours before putting them in a big jet does not automatically produce skygods and in fact may even exacerbate this sort of situation? The current system is not set up to emphasise and require high quality training, it is set up to shove people through the bare minimum at every level and hope that "experience" covers up the deficiencies. By preventing larger airlines like Atlas from hiring and training from scratch - instead they have to rely on the training departments of all manner of tinpot carriers to provide that all important formative training. The number of hours spent performing a task are a pretty poor marker of competency. You only have to look at driving, golf, or indeed our own hobby of flight simulation to see that. Yet in aviation we still place far more importance on the sheer number of hours logged than the quality of the training or type of experience. Practice (which is all hours really represent) is only really worthwhile if the individual has been properly trained in the task to be carried out, coached and monitored to ensure that they are carrying out in the correct manner to a high standard. I could go and play golf every day but without the right coaching it's not going to make me Tiger Woods. Even with the right coaching I'm unlikely to attain that sort of standard, but I'd still be better after the same number of hours of practice than if I had a substandard coach or simply got on with it myself. The common link in almost all 'pilot error' type accidents is not the number of hours in the log, but a consistently poor training record, with failings inadequately remedied or glossed over. HR and the hiring process has a part to play in this, but so does the overall system and the approach to and investment in training vs simply looking at experience.

Quite. Presumably ORD ATC will be declaring emergencies for every B737, B757, B767, B777, B787, A320 etc turning up with only two engines operating! 😁

There are a number of standalone Hoppie clients (such as the one you linked) which can be used, at a basic level, to send and receive CPDLC messages, with any aircraft. However, they are completely separate pieces of software and do not interact with the aircraft itself in any way, so for example you will have to re-enter all your flight details in to the standalone client and it obviously will not interact with anything in the aircraft (so you cannot uplink ATC reroutes direct in to the FMGS, transfer radio frequencies in to the RMP etc, position reports have to be fully manually filled rather than taking information from the FMGS etc). Because the FSL A321 has it integrated as part of the aircraft all of this is much smoother and just forms part of the normal course of operating the aircraft.

I have to say I'm with @FDEdev here... I'm not really sure what such a gauge would add beyond the visual and physical cues that are already there. I mean, you can already feel the force required to hold the stick out of centre... because you're already holding the stick out of centre. If you can't feel the difference between the stick being centred or not, or see the nose attitude move up or down, then I'm not really sure a gauge is going to make a lot of difference. Hold the attitude, trim, and gradually release the pressure on the stick so that the attitude doesn't change when you are trimming. Obviously if you just let go and start trimming and hoping for the best (I'm not saying this is what you are doing, but it's what I see a lot of simmers doing) then you won't feel anything, and if you hold the stick in a constant position whilst you trim that isn't going to work either; the actions have to be coordinated. Just focus on holding the attitude steady...

I can make no comment on the way that Navigraph have chosen to present the change, but Aivlasoft EFB is actually probably an excellent example of why I suspect the tables have turned. 20/30 years ago, charts would have more or less literally been drawn and printed, or gradually as time progressed converted to electronic format and distributed fundamentally as straightforward images. Hence Navigraph/Aerosoft would have purchased and been sent PDF copies of the charts to then distribute. Nowadays, especially with the focus on EFBs and 'smart' charts with georeferencing, the ability to declutter information at various zoom levels etc, a chart is simply a visual presentation of the navigation data -- fundamentally it's no different to the FMS data at all, it's just that the chart presents the data in human-readable format whereas the FMS data is in a machine-readable format. The value therefore, and what Jeppesen will be charging a premium for, is the data, not the chart itself which is just a presentation of it (as you know yourself - Aivlasoft are basically doing exactly what Jeppesen are probably doing at source to create their charts). I wouldn't be suprised if Jeppesen simply provide Navigraph with a raw database and then most of the charts themselves are parsed and created from that at Navigraph's end, along with the FMS data files. Essentially, you are paying for the data and the charts created from that data are being thrown in.

I understand your point of view but I think you're missing the point I was making slightly: I am guessing (and it is just a guess) that the driver for the change is that the navdata is now what is costing Navigraph large amounts of money, not the charts. In other words -- maybe the Charts customers were actually paying for FMS data that they don't necessarily need, and in doing so subsidising cheap subscriptions for those of us who were on FMS data only. I'm neither defending nor disapproving of Navigraph - at the end of the day though as simmers we don't need up to date charts or FMS data, they're nice to haves. If we were flying in reality, we would genuinely need this stuff and we'd be paying a heck of a lot more than €10 a month for it. At least we have pretty much a genuine choice -- if you don't want the bells and whistles Navigraph product, Aerosoft have an equivalent FMS data product which is slightly cheaper than Navigraph's FMS data subscription is/was, and they're very flexible (you can buy one cycle only, four updates a year or the full 13 updates) albeit they do not support a small number of addons which Navigraph do. Or not update at all safe in the knowledge that the CAA aren't going to take your licence away! 🙂

It's a difficult one. I had a Navigraph Ultimate subscription for many years; I dropped down to FMS data only a couple of years ago after they changed to Jeppesen charts because I just wasn't a fan. Thus, I've been using Navigraph navdata and Aerosoft charts. Reading between the lines, my guess is that at least at their end the distinction between navdata and charts is becoming increasingly blurred. I'm guessing that with all the georeferencing (moving map stuff) etc that Navigraph themselves these days are largely dealing with data which is then generated in to charts, rather than buying a set of charts per se from Jeppesen which are subsequently distributed. In other words -- it's probably increasingly the navdata which is the 'expensive' bit of the subscription, not the chart graphics themselves -- so those of us who were on FMS data only were probably being subsidised by those paying for charts as we were getting, from Jeppesen's point of view, the same data but at a fraction of the price. On a personal level, the difference in cost between what I'm paying now (Navigraph data + Aerosoft charts) is negligible compared to a Navigraph Ultimate subscription and no Aerosoft charts so I will probably suck up being stuck with Jepps as being able to update Simbrief's navdata is important to me and I can't fault the Navigraph product -- the work they have done since moving over to the georeferenced charts in terms of integration with Simbrief, enroute charts, moving maps, iPad and desktop apps etc is absolutely incredible, really nice and really impressive. They were also very helpful and responsive support wise when I had an issue a year or so back -- my only beef with them is the Jeppesen format. I think it is worth noting as well that even at €120 a year for what is provided (worldwide FMS data, worldwide georeferenced terminal and enroute charts, very professional and slick apps etc) is an absolute steal -- Jeppesen charge airlines and individuals thousands for this data, especially for worldwide coverage. It's big business, so the fact that as simmers we are able to access it at an even vaguely affordable price is quite something (the same is true obviously of the Lufthansa Systems based Aerosoft product). That said -- if Aerosoft were able to work out something in order to be able to update Simbrief I'd probably switch over for the Lido chart layout. If you don't have any chart requirements and you're not fussed about Simbrief then as Ray says Aerosoft navdata is an obvious straight alternative.

Hi @ShortyME, The best place to start is probably the Swift section of the main VATSIM forums (here) -- the developers monitor that and should get back to you. I'll see what else I can find out for you as well! Best, Simon

Hi there, @krazyk has almost nailed it. On the fuel data page (page 1) first: 0835 is the scheduled time of arrival with a space to enter the actual time of arrival (on blocks) Similarly 0725 is the scheduled off-blocks time with space to enter the actual off-blocks time (UTC). It's in that order (STA above STD) to make it easier to do the sums! 0110 is the scheduled total block time with space to enter the actual block time. PL - Planned Payload with space to enter the actual figure HOLD W A - enter any time spent holding and 'ring' the reason (Weather or ATC). TNKS - space to record the initial fuel (at the start of the flight) LEFT - space to record fuel remaining at the end of the flight USED - space to record fuel used (i.e. TNKS - LEFT) ACH FL - Achieved Flight Level. The maximum flight level achieved during the flight if different to the planed level. TRIM - Stabiliser trim setting MIN COST VAR SPD - the parameters used for the calculation of the flight plan (minimum cost, variable speed -- in reality you might see things such as MIN FUEL, MIN DIST, LONG RANGE CRUISE, MAX ENDURANCE for the parameters, whereas speed can be planned at VAR SPEED (variable speed, i.e. Cost Index) or a fixed speed schedule such as SPEED 320/0.80, but I don't believe Simbrief simulates any of these parameters so you will always see MIN COST VAR SPD). TUF/LFOT is the alternate airport in IATA and ICAO codes. FL230 is the height at which the diversion is planned. M18 is the average wind component used for the diversion calculation -- this is a headwind component of of 18 kt (M = headwind, P = tailwind). PLAN REM - planned fuel remaining at touchdown. This is the sum of CONT + DIV + RES + ETOPS + EXTRA (in tonnes, rounded up). In all cases the only planned usage is TIF + TAXI. TOT RES - total reserve fuel -- i.e. final reserve + diversion fuel (in tonnes, rounded up). On the navlog page (page 2): WAYPOINT COUNT 8 CWC 8 (NOT TOC/TOD) - this page lists 8 waypoints and the cumulative total so far of all pages in the flight plan (Cumulative Waypoint Count) is 8. This total does not include TOC/TOD (top of climb/top of descent) points. This is included as a means of checking that no data has been lost or garbled in the transmission of the flight plan. MSA - Minimium Safe Altitude for the route leg (thousands of feet) -VAR- Variable track (usually shown during SID/STAR legs -- the real Cirrus OFP truncates SID/STAR waypoints) TIM - time in minutes from this waypoint to the next waypoint (consider 0 for calculation purposes if blank) TTLT - total elapsed time to the waypoint from brake release on the takeoff roll REQ - fuel required from that point to touchdown - in you example 1.7 tonnes from departure. When you are filling out the plan to do fuel and waypoint checks you would enter the takeoff time in the ATA column at a convenient moment after departure (I would suggest waiting until you are above FL100!). You then add the TIM figures to get ETAs at each waypoint (e.g. say you get airborne out of Heathrow at 0750Z - you would write 0750 in the ATA column for the HEATHROW waypoint, then add 0 (because there is no TIM figure underneath the HEATHROW entry) and write 50 in the ETA column for D257E, add 1 minute to that to give 51 as the ETA at D161I and so on until you have worked your way through the flight plan. When you overfly a waypoint you can then record the ATA in the appropriate column to compare your progress to the OFP and the actual fuel remaining in the REM space. Subtract REQ from REM and that gives you your estimated fuel on arrival, which you can compare to the PLAN REM and TOT RES figures as well as the FMC prediction. Here's an example. Hope that helps!

As others have said -- where exactly have you been looking for support and failing to find it? We have a forum section on the main VATSIM.net forum site which we are monitoring and responding to on a constant basis, we keep an eye on the VATSIM Facebook groups, I keep an eye here and over the last 36 hours every time there's been a problem I think Mark or Gary has got it back up and running within a matter of minutes, with the exception of a short outage that happened in the early hours of this morning UK time. Happy to look for feedback anywhere else you think I should be, of course, and as others have said -- if you can elaborate on your problems I will be only too happy to help out and/or feed it back to the team! Simon - with AFV team hat on 🙂

This is a Windows setting. Right click the speaker icon in your taskbar, select Sounds, go to Communications and under "When Windows detects communications activity" select "Do Nothing".

In the menu on the left hand side there are links for users of all the current pilot clients: vPilot, xPilot, xSquawkbox (for X-Plane), swift and others (i.e. anything which is not the above, so Squawkbox and FSINN). https://audio.vatsim.net/docs/1.0/pilots/others

Hi @CaptDennison, No worries - I do totally get that it is hard sometimes to update or leave behind something which otherwise seems satisfactory, which is why I'd rather try and outline why I think it is worthwhile! If it were just a straightforward change of codec but otherwise retained the same basic functionality as the current voice system I wouldn't have thought it was worthwhile breaking everything for that, which is why we really wanted to push the boundaries and create something groundbreaking and really immersion-enhancing. Now - everybody's experience of this is going to differ but what I can say is that we have had dozens of real-world air traffic controllers and pilots from around the world -- from the FAA, NATS in the UK, Eurocontrol, Greece, Iceland, Australia and many others, as well as airline and GA pilots -- involved throughout the development and their feedback is that what we have created is a very, very close representation of their experiences. There are definite regional differences - as a generalisation the UK and Eurocontrol guys generally felt that it should be clearer, the Athens guys thought it should be much worse and the US guys were somewhere in between, but I think we've found a happy medium which seems to have made all of them happy 🙂 The transmissions do include static (sampled from real recordings from inside actual aircraft, not generated) and range degradation effects - so the further away you get from the source of the transmission the more crackly it becomes until eventually it becomes totally unreadable. This also means that your experience of transmissions is absolutely unique -- if another pilot a long way away from you transmits, you will hear them with lots of static and crackle but a more nearby pilot or controller will hear them much more clearly. We have also created an HF simulation for long range and Oceanic ATC (which may be a bit closer to your shortwave CB radio that you may be used to from your truck I guess?) which includes even more hiss, whine and crackle. One of the most immersive experiences we had was the other day during a test of the HF simulation when we were coming off the Atlantic (having been on HF) and were handed over to Gander domestic -- when we first called up, out over the Atlantic, the controller was really faint and crackly - but as we got closer to landfall of course the signal improved and became much clearer. It really added to the feeling of being out over the ocean! The squelch, currently, is automatic - which is in line with all the aviation radios I am familiar with but if you are aware of an aircraft or ATC radio which has a user-controllable squelch do let me know and who knows, it might become an option in future! Certainly not! None of the transmissions are recorded and the servers are hosted by VATSIM as an organisation, not any of the AFV team personally. If you head to https://audio.vatsim.net you will find more details about how to get set up. Essentially there is a small, lightweight Windows desktop program to download which you will need to run alongside Squawkbox (a bit like you may have used to run Roger Wilco or AVC alongside Squawkbox many years ago). Definitely no phone required! Swift is the only FS9-compatible client which is actually being supported by its developers. As I said earlier, I believe the main reason its FS9 functionality is still listed as Experimental is because they are really short of beta testers with FS9 so they have developed it but they need support from the FS9 community to help refine it. I am not a Swift expert but if you head to the main VATSIM forums there are many people there who would be only too happy to help you get set up with Swift. I totally get why you want to stick with FS9 -- but personally I would say the best way for the FS9 community to ensure that FS9 remains supported by VATSIM is to get on board with Swift and help the Swift development team take their FS9 functionality from 'experimental' to 'rock solid' -- if no FS9 users adopt and support the only client that supports FS9, why would that client's development team stay motivated to include and improve FS9 capability? Hope that helps and feel free to shout if you have any further questions. Best, Simon

Hi there, If you have looked at the feature list and you honestly don't beleive that any of: - A realistic VHF and HF radio simulation including real radio propagation characteristics, real radio operating characteristics, realistic sound effects, range degradation effects, multi-frequency cross-coupling for controllers, voice CTAF and Unicom, air to air communications on any frequencies, realistic call blocking and much more to come in future updates such as terrain occlusion and atmospheric effects - A reduction in latency from about 1.2 seconds to around 150-200ms - Fewer crossed and stepped on transmissions - And more Will make your VATSIM experience better or more immersive in any way, then I'm sorry that I and the rest of the development team have wasted the last year of our lives and literally thousands of man-hours coming up with such a disappointing product! The current codec may be just fine for you but it literally excludes thousands of VATSIM members who are hard of hearing (even with VHF effects off it is too mushy to work well with hearing aids), who have suffered from medical issues which have affected their voices (I know at least one guy who is immensely looking forward to returning to controlling on VATSIM as he gave up because pilots just could not understand anything he said), and non-native English speakers whose number one complaint is that they simply cannot make out ATC and so either do not fly on the network at all or use text only. All that said - if you read the announcement you will see that you will still be able to use Squawkbox if you wish but you will need to download an additional voice client, because the Squawkbox developer abandoned that software around a decade ago and kept the source code to himself so nobody can update it. That said, at some point in the future there really will be no option to update because things like smoother aircraft position updates really won't be compatible with the abandoned clients. Swift does, from what I understand, work with FS9 and I know the team really would appreciate more FS9 users giving them feedback to improve it - from what I can gather the main reason FS9 functionality is still listed as 'experimental' is because they literally could not find any FS9 users to help with testing it. I genuinely would be interested to know what more you would have liked to see from the new system to make it worth your while -- perhaps we can make it happen!

Absolutely -- I am not disagreeing with you (although as I say, there is a difference between flow rate per hour and the number of aircraft on frequency at any one time which is obviously a function of flow rate and the average amount of time taken for an aircraft to transit through the sector. 60 to 80 aircraft an hour isn't 60 to 80 aircraft on frequency simultaneously -- if it only takes an aircraft two minutes to transit the sector, for instance, then if my maths is right -- which it probably isn't -- that would only be about three aircraft on frequency at a time. Obviously it will be more than that in practice). My only point was to give the VATSIM guys a little bit of credit that despite the fact they have none of the things you have listed above (well, I suppose the radar is OK and hopefully in two weeks' time we we be able to say they have excellent radios as well!) if they are able to work 10 aircraft simultaneously then it can be said they are reasonably achieving anything up to about 70% of the (instantaneous) capacity of the real equipment and controllers and I think that is a pretty good effort!