[jhb_airlines] Re: FPI last night

  • From: "Bones" <bones@xxxxxxx>
  • To: <jhb_airlines@xxxxxxxxxxxxx>
  • Date: Wed, 11 Aug 2004 19:17:24 +0100

Thanks Gerry - some good points there. 

Brian and I both used the current CAA diagrams for Manchester. I had the
SID/STAR and Radar Vectoring Area charts and Brian had the aerodrome and
apron charts. In FPI the former are fine but the differing sceneries
make the latter difficult to use. You can't really supervise aircraft
that seem to be taxying down routes totally different to those showing
on the radar screen - especially if they are mixed up with other
aircraft who are located correctly. The best you can do if just give
vague guidance to a runway or stand. 

Brian isn't new to ATC but he's not had any experience with any volume
of traffic. I think the most he has had in any of his sessions has been
three aircraft - and I admire his perseverance in staying with FPI for
so long. A sudden increase in traffic and at a reasonably complex
airfield did push his abilities a bit. Bear with this - Brian is an ex
BA captain and so sitting on the other end of the tube is a novel
experience for him. As he admitted, it isn't as easy as it first looks!
<g>

Taxying in turboprops is a pain but this is true to real life - not just
a quirk of FS. When you lift the power levers into the Beta range the
props change pitch quite significantly and you have an instant increase
in thrust. Most turboprops will rapidly accelerate to a good speed (as
you found) and so it is a constant juggle of braking and power levers to
keep speeds to sensible levels. It's not a good idea to keep permanent
brake pressure on as they get too hot - and would lose efficiency if an
aborted take off was necessary. This is one reason why they now have
brake temp gauges - if these get too high during a long taxi some
aircraft will have to sit at the hold until temperatures come down to
acceptable take off limits (this can take some time). Anyway I digress.

The Portuguese pilot is a brave man. I think this is only his second
flight in FPI - I controlled him a few days ago on his first flight. It
was no problem to me but a newbie for Brian was probably bad news in the
middle of his first busy spell. However this will always happen and is
one reason why we have to maintain a "flexible" attitude when using the
system. It means not getting uptight if someone starts up in FPI and
takes off from your airfield without talking to you - this happened
earlier this week and I could only warn my inbound aircraft of
unidentified traffic.

Having said that there is one trap that us ex professionals fall into
and I spotted this on Tuesday - and must apologise for it. The FPI
simulation is quite realistic as you have the radar screen, strips and
voice coms as in real life. This leads to what I noticed was a
"switchover" point. As traffic levels increase the workload obviously
rises but, at some point, they reach a level where I switch over to
professional mode. That is to say that the workload now requires my full
attention to resolve the traffic. At that point the session is no longer
a simulation to me but a true radar control environment in which a lot
of traffic needs 100% attention.

Some of you may have noticed this point as two things happen. First the
chat stops (I don't have enough R/T time to permit it) and, secondly,
the RT becomes a lot crisper and faster as I need to say a lot in a
short time. This is totally automatic to me - I didn't realise I was
doing it - but is simply the result of the traffic levels reaching a
point where you get locked into the session. In some ways this is good
because you are getting "professional" service but it has a downside in
that I automatically become authorative and slightly intolerant. 

A good example is if I have put an aircraft on a base leg for the ILS
and am about to turn it onto a closing heading. This is quite critical.
If you turn the aircraft in too early it will intercept the ILS at say
8nm instead of 10nm and this means the aircraft is descending on the GP
before it becomes established on the localiser - not a good thing. If I
leave the turn on too late then the aircraft will go through the
localiser - also a bad thing. If someone starts to talk on the R/T just
as I am about to turn an aircraft in it can really mess the approach up.
In real life all R/T calls are kept short and this problem doesn't
happen (often) but any lengthy call in FPI at the wrong moment can
equally mess the approach up - and so I sometimes get slightly rude in
that I will cut in on some of you or acknowledge your call very curtly.

This isn't personal. R/T time can be critical and it is sometimes
necessary to interrupt a pilot's call. Putting it another way I am sure
you all prefer to have a nice vector to the ILS rather than get a late
call which messes up your approach.

So, when it gets busy, please accept that I may shift up a gear or two
and go into real ATC mode. I think you appreciate this in the long run
but it may jar on sensitive personalities. <g>



> -----Original Message-----
> From: jhb_airlines-bounce@xxxxxxxxxxxxx 
> [mailto:jhb_airlines-bounce@xxxxxxxxxxxxx] On Behalf Of gwinsk@xxxxxxx
> Sent: 11 August 2004 06:33
> To: jhb_airlines@xxxxxxxxxxxxx
> Subject: [jhb_airlines] Re: FPI last night
> 
> 
> Perhaps I benefitted from being on the session from early on, 
> last evening. I had no 
> problems until trying to change to the Tower frequency. 
> Manually inputting the 
> necessary info didn't work but, with only a couple of miles 
> to go, a ping announced the 
> arrival, in the ATC slot, of the Tower frequency. The 
> changeover was then immediate, 
> which is where I hit the first problem. I was using the 
> UK2000 scenery and flying the 
> Brian Stone B1900D. This is one of the turboprops in which, 
> perhaps like real life, taxi 
> speed control is very difficult. With the throttles closed, 
> it will rush up to 40 kts. This can 
> be prevented only by hitting the F1 ket, or assigned Yoke 
> button. This stops it, in short 
> time. Combine the concentration this demands, with the many 
> evening green taxiways 
> and the basis for a nightmare exists. In most cases switching 
> in the overhead view 
> helps. Not at Manchester, where, at all but one Zoom setting, 
> the photographic 
> background prevails, in this view. Manchester may be a case 
> of the "VFR Compatible" 
> description being better read as "incompatibillity 
> disguised"!  My guess is that the controller has a chart on 
> screen. At the pilots' end, whether the 
> chart obtainable via ATOC is visible, is down to monitor / 
> graphics card / driver 
> combination. It's therefore very difficult to follow 
> instructions on taxiway routing. Whilst on the ground, I 
> noticed the differing paths taken, as a/c landed and taxied. Like 
> you, I can't see a way round this scenery variation problem.  
> Back to taxiing; I'll look to see if top view is improved, at 
> night, by disabling the VFRGM 
> scenery. That's easy enough to do if running in FS2002. It's 
> not if using FS9.  I'm not sure why we needed to face SW, 
> after pushback, but that left me looking into a 
> taxiway free zone. On attempting to leave for IOM, the first 
> problem was that Flightplans 
> weren't getting through. The next was that the taxiing 
> problem was magnified by the use 
> of 24L, for some departures. In my case I lost the plot and 
> finished up en route to 24R 
> hold. At that point I decided that the easiest way of not 
> causing a blockage was to exit 
> MP. One of the factors in this decision was the risk that I 
> might get in the way of the 
> Portugeses Easten pilot. My hat off to the chap, for patience 
> above and beyond the call 
> of duty. He must have been hanging around for the best part 
> of 45 mins, waiting for 
> clearance. I took a look at his Infoserve Plan, in which he'd 
> noted he was a novice and 
> didn't know how to fill in the details. I drew this to 
> Brian's attention but, though his voice 
> didn't reveal it, he must have been becoming quite stressed, 
> by that time.
> 
> If two controllers are available, then manning the two 
> frequencies enhances realism. 
> Last night showed up problems but, in my opinion, it's worth 
> persevering. 
> 
> Gerry Winskill
> 
> gwinsk@xxxxxxx
> 
> 
> 
> On 11 Aug 2004 at 2:37, Bones wrote:
> 
> > Last night's session seemed to go reasonably well for most 
> pilots but 
> > it was headache for a few. What I would like to know is the 
> problems 
> > anyone got into so we can sort them out.
> > 
> > So far I have identified the following problems:
> > 
> > 1. Some aircraft did not appear on the radar screen
> > 2. Some aircraft could not be locked with an ATC service (I won't 
> > explain this yet) 3. Some aircraft could not be handed over 
> correctly 
> > (linked with above) 4. Some aircraft landed on the wrong runway 
> > (actually you didn't but see below) 5. Frequency changing 
> didn't work 
> > well.
> > 
> > Any other for the list?
> > 
> > I suspect that one of the major problems last night was 
> that the FPI 
> > servers may not have all been talking to one another. When I asked 
> > Peter to turn off the Server button for a few seconds and reconnect 
> > his data came through fine. However this trick didn't work for Mike 
> > and although I could see G-CART on the radar screen Brian 
> saw nothing
> > - until Mike changed over to a different server.
> > 
> > This is definitely server related and to ensure it does not happen 
> > again can I suggest we all log in to the same server in 
> future. I use 
> > 217.172.179.54 - simply because the ATOC setup always 
> defaults to the 
> > server at the top of the list and this is what the majority 
> of traffic 
> > gets stuck on. Going to 217.172.179.54 means we get a quiet 
> server and 
> > avoid any need for the servers to behave themselves.
> > 
> > The same goes for voice - I always select 
> fsd.flightproject.de these 
> > days for both channels and I suggest everyone does the same.
> > 
> > Item 2 has me baffled but I need to read the docs to find out what 
> > causes it. Basically if you come on my frequency FPI locks 
> you to me. 
> > This turns your data tag on the radar screen to green and 
> stops other 
> > controllers from taking you over. It also allows a bunch of 
> extra menu 
> > options including a handover facility and this leads on to item 3. 
> > Handovers should be automatic and this didn't always happen.
> > 
> > Item 4 is going to be a permanent headache because it is related to 
> > the scenery you use. Some of you were using the UK2000 scenery last 
> > night but some were on the default scenery. The airports in 
> UK2000 are 
> > displaced and it just happens that the displacement is 
> pretty near the 
> > same distance as the gap between the two runways. The 
> result was that 
> > some of you flew down the runway centreline on the radar screen 
> > perfectly but others appeared to be flying down 24L.
> > 
> > The default airfield map on the radar screen is based on 
> the default 
> > FS airfield and this is where the second problem hit Brian. Some of 
> > you were taxying down the taxiways shown on his screen but 
> others were 
> > apparently taxying on the grass. If one aircraft was using 
> the UK2000 
> > scenery and given a taxi route to follow and then a second aircraft 
> > was asked to follow the first (but was using the default 
> scenery) the 
> > second pilot would have been extremely puzzled in the route of the 
> > first!
> > 
> > I don't know the answer to this question but it will cause a lot of 
> > problems with any ground ATC ops. If I tell you to park 
> next to JHB007 
> > you may refuse because he is buried in a building on your setup. It 
> > would help if we all stuck to the same scenery but I don't want to 
> > impose this on anyone.
> > 
> > Item 5 could be caused by a couple of problems - 
> particularly those of 
> > you using networks. It was Kevin who finally gave a clue as to this 
> > enigma - yes, he eventually connected and even managed a couple of 
> > flights last night. Everything went well until I put him 
> over to Brian 
> > on final at Birmingham (don't ask). The handover went 
> according to the 
> > book (on the ATC side) but Kevin didn't apparently change 
> frequency. 
> > He had - but this is where something went wrong. Here is 
> what I think 
> > happened.
> > 
> > 1. Kevin was using a copy of the voice module on Computer 
> A. This was 
> > fine as long as he stayed on the one frequency. 2. When asked to 
> > change to EGCC_TWR Kevin correctly opened the ATOC ATC box 
> and double 
> > clicked on the ATC position. 3. For some reason this action 
> launched a 
> > second copy of the voice program (possibly on Computer B) which 
> > resulted in Kevin listening out on three frequencies - 
> mine, EGCC_TWR 
> > and the chat frequency. Unfortunately he was still only able to 
> > transmit on the original frequency although it looked to 
> him like he 
> > had correctly changed to Brian.
> > 
> > This may also have happened to a few of you - I'm thinking 
> of Tom here 
> > as he was the first to hit this problem last night. I 
> didn't ask Kevin 
> > if he ended up with two headset icons on his desktop - and I didn't 
> > find out how he cured it - but we need to look at this 
> further. It may 
> > explain some problems we have had in the past when pilots 
> could hear 
> > but not transmit.
> > 
> > None of these are serious headaches in FPI operations but 
> they are the 
> > next step in our learning curve - in this case as we introduce a 
> > second ATC position.
> > 
> > HC@xxxxxxxxxx
> > http://fsaviation.net
> > 
> > 
> 
> 
> 


Other related posts: