[jhb_airlines] Re: FPI last night

  • From: gwinsk@xxxxxxx
  • To: jhb_airlines@xxxxxxxxxxxxx
  • Date: Wed, 11 Aug 2004 06:32:30 +0100

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: