FMC nav radio page

[Hardy Heinlin]

Good morning,

has anybody ever tried to enter in line 1 an identifier of a VOR that is more than 250 nm away?

Some FMC manuals say this would result in an INVALID ENTRY message. But there's at least one aircraft (with a kangaroo on the tail) whose FMC has no such 250 nm limit.

I'm wondering if this is a new FMC standard or a customer option perhaps?

I think if the entered identifier is one of multiple VORs, the FMC will take the nearest station as there's certainly no manual selection page in this case.


Cheers,

|-|ardy

[delcom]

No range limit for our 744's (at least not 250nm).

cheers,
d

[Hardy Heinlin]

Thanks. I assume it's a new standard.

I'll increase my limit to 640 nm and take the closest station in case of multiple stations with the same frequency.


|-|

[Hardy Heinlin]

Ah, no, it's getting to complicated. I'll use 320 nm. If I would take 640 or no limit at all, I had to introduce a special program for identifier management; in dense areas like Europe or the USA, when I enter an ID of a station which is, say, 600 nm away, the FMC database will provide the frequency for that ID, tune that frequency and ... will most likely receive a station closer than 600 nm with that frequency (with a different ID); the CDU would then indicate the desired ID, and the ND would show the actual decoded Morse ID (a different ID). In my code, however, the CDU ID and ND ID are the same variable.


|-|


Edit: 320 is still too high. I just set it back to 250. I'll write in the PSX manual that the real FMC may use 250 or no limit, depending on the FMC version, and PSX uses 250, too.

[Jeroen Hoppenbrouwers]

I do understand that in this particular case you intentionally simplify the system and unify entered ID and received ID.

The green T-lines on the ND ("POS") will deviate from the ND beacon symbol under map shift and long-range circumstances, right?


Jeroen

[Hardy Heinlin]

Only the three-letter ID is a common variable in my code. It wasn't my intention to simplify it, it was just my understanding that the logic goes like this:

1. Pilot enters a VOR ID on the NAV RAD page.

2. FMC searches in the database for the corresponding frequency.

3. FMC sends that found frequency data to the VOR receiver.

4. VOR receiver is tuned and may or may not receive a signal.

If received: *
_ 5. NAV RAD will display the VOR ID when the Morse is decoded.
_ 6. ND will display the VOR ID when the Morse is decoded.

If not received:
_ 5. NAV RAD will not display the VOR ID.
_ 6. ND will not display the VOR ID.


* Then I learned that it should be like this:

If received:
_ 5. NAV RAD will display the VOR ID immediately.
_ 6. ND will display the VOR ID when the Morse is decoded.

So far no problem if only one common ID variable exists (the sim knows the ID immediately, it just doesn't immediately show it on the ND).

With two different IDs, however, a lot of new code must be implemented that has a continuous inhibit logic and display logic and an ID/frequency check so that the set frequency is tuned only when the desired ID agrees with the received ID and so on ...

A lot of work just for the case when a VOR ID is entered that is far out of reach. Who needs that?

The T-lines are a separate story. That's no problem.


|-|

[Hardy Heinlin]

The (real life) problem is this:

It may happen that a Morse signal cannot be automatically decoded (the pilot must then do it with the ears). Say, JFK is set and parked, and you're flying in an area where VOR ABC could be received (same frequency as JFK), ... but since ABC is unequal to JFK, the signal is inhibited ... the FMC is waiting for an ID confirmation from the Morse decoder, but JFK is not coming ... so ... what happens? Is the VOR tuned anyway? Or is it off?

If the VOR is tuned anyway, another problem occurs: ABC is tuned and displayed all the time: ND shows ABC, NAV RAD shows JFK.

So what? :-)

[Jeroen Hoppenbrouwers]

Are you sure that there is any machine check of the ID, on top of just plain decoding and displaying?

How about this scenario?

1. Pilot enters VOR frequency on CDU.
2. Radio manages to get a signal.
3. A Morse ID is decoded.

Where does the Morse ID show up now? ND and CDU?

Next scenario (notice just one extra step):

0. Pilot enters VOR ID on CDU.
1. FMC converts ID to frequency.
2. Radio manages to get a signal.
3. A Morse ID is decoded.

I am not sure whether the entered ID is used at all for anything, except for immediate display on the CDU. And I doubt whether the comparison between entered ID and decoded ID takes place. The interesting experiment would be to find a VOR in range with the same frequency but a different ID, and see whether the ID swaps after decoding, but for obvious reasons this is difficult to do.

So, is the entered ID just used as a lookup and the rest of the system works just from frequency? This would appeal to me, as it is a clear, unambiguous system that can be implemented straight away. Adding automagic comparison of entered and received ID would only make sense if after detecting a mismatch, some noisy notification is given.


Jeroen

[Hardy Heinlin]

I don't know either. But if the entered ID would be used for determining the station, it would probably not use the Morse decoder (as I thought yesterday), but the lat/lon comparison between FMC position and VOR database position. I.e. tune the desired VOR (per ID selected) when the FMC position is within, say, 250 nm of the VOR database coords.

If I recall correctly, autotuning includes in its "reasonable checks" some sort of ID checking in order to be sure that the database station agrees with the received station; but I may recall incorrectly and the autotuning just tests the database coords.

Here's another problem: Assuming the FMC is waiting and not tuning the radio until the ID-entered VOR is in range, what would be displayed on the ND in that time? The parked frequency or the ID ... or nothing? Whatever it is, it would look unusual.

...

Of course, the easiest way would be to leave it as it is now (in Alpha 35), i.e. just use one common ID for both the entry and the signal. But then we have to accept that the following may happen:

1. Enter ABC
2. FMC tunes ABC's frequency 112.00
3. CDU shows ABC, ND shows 112.00
4. Morse is decoded, ND shows XYZ, CDU changes from ABC to XYZ


Chees,

|-|ardy

[Hardy Heinlin]

If you fly in Europe with 112.50 tuned, you will receive a new station about every 100 miles. Would the CDU display keep the originally entered ID or always change to the decoded Morse ID?

[Hardy Heinlin]

Here are two test examples, if somebody wants to try it ...

:-)


When you are at EHAM and enter RSV (a VOR in the USA) on the NAV RAD page, will the NAV RAD page indicate RSV or SPL? Both have 108.40.


When you are at YSSY and enter MGM (a VOR in the USA) on the NAV RAD page, will the NAV RAD page indicate MGM or SY? Both have 112.10.


Cheers,

|-|ardy

[John H Watson]

When you are at EHAM and enter RSV (a VOR in the USA) on the NAV RAD page, will the NAV RAD page indicate RSV or SPL? Both have 108.40.

Wouldn't the ID entry simply be treated as a manual frequency entry? (i.e. the frequency is sent to the VOR receiver, irrespective of range). The VOR receiver doesn't know you are too far away from the station.

The CDU ID would probably disagree with the ND decoded ID.

[Hardy Heinlin]

Watson! Good to see you, old friend :-)

The CDU ID would probably disagree with the ND decoded ID.

That's what I'd like to know. If it disagreed, I had less work.


Cheers,

|-|ardy

[Zinger]

1. I have no current way to verify whatever happens on the real aircraft. However it would be unacceptable design if after inserting a VOR ID, the receiver tuned into another station, regardless of frequency commonality, even if cockpit displays showed a different and actual station code.
2. Maybe relevant to Hardy's questions, from the real world Ops manual:
"Navaid Identifier Decoding
The Morse code identifier of a tuned VOR, ILS, or ADF can be converted to alpha
characters. The decoded identifier displays on the PFD and ND. Monitoring this
identifier ensures correct navigation radio reception. The identifier name is not
compared with the FMC data base.
Due to the large variation in ground station identifier quality, the decode feature
may incorrectly convert the intended identifier name. Examples: the Hong Kong
localizer "KL" may show as "KAI", or the Boeing Field ILS may show as "QBFI"
or "TTTT" instead of "IBFI.""

[Jeroen Hoppenbrouwers]

... if after inserting a VOR ID, the receiver tuned into another station ...

If the database contains a simple ID --> frequency table, and if stations operating on the same frequency have by definition exactly the same signal (both VORs), it cannot be avoided that the receiver tunes into "another" station. This is why there is an ID broadcasted, which you can only decode after having tuned.

The only way out would be to not allow a conversion ID --> frequency when the ID's position (from database) is more than a safe number of miles away from present ship position, reasoning that this station cannot be reliably picked up and tuning is irrelevant (and may even pick up another station which is closer by). This means that under these circumstances, the machine must reject the ID ("illegal entry").

Recent experiments on the real thing have revealed that there seems to be no such minimum limit. Therefore, it is possible the design is unacceptable by your standard, yet flying around in several hundred aircraft.

Having an ID --> frequency database does not relieve pilots from visually and, when in doubt, aurally identifying the station, either VOR or ILS.


Jeroen

[Zinger]

Jeroen,
I've just added item 2 to my message above yours, for your info.

[Zinger]

1. The case where two stations on the same frequency have equal signal reception strenth, is  encountered for very short time periods, therefore presenting no real opperational problem. It results from the aircraft velocity.
2. About my standards- I meant to say (and if necessary am correcting)-  tuning into one station and receiving another, is unacceptable to me. Boeing to avoid such case, resulting from wrong decoding and displaying of the transmitted station Morse code, has issued the note I posted above. NASA, Boeing, Aerospatiale, Northrop, Sikorsaky, IBM, Bell to metion a few dominant players in Aerospace, generally accepted my standards and paid handsomely for them. Using audio reception for station ID by the pilot is mandatory.

Edit: One of the aircraft which utilizes a design not according to my standards, is the TU-154M, like many other Russinan aircraft. As example, their main Attitude display instrument articulates the aircraft image for bank angle, rather than the background earth, as is common in most western systems. It creates to the human opposite situation orientation.

[Hardy Heinlin]

The latest tests on real ships have shown that on this subject the current FMC versions don't agree with older FMC manuals.

Old:
A three-letter-ID entry of a VOR is valid if that VOR is found in the database and within 250 nm of the present FMC position.

New:
There's no 250 nm limit anymore. The entered ID, if found in the database, remains displayed on the CDU even if another nearer station exists with the same frequency and different ID. -- Still unknown: What is displayed on EFIS and is the VOR receiver then parked or not?


|-|

[Jeroen Hoppenbrouwers]

Zinger: I honestly think we totally agree, and I tried to be accurate in my wording. You said:

However it would be unacceptable design if after inserting a VOR ID, the receiver tuned into another station, regardless of frequency commonality.

to which I replied that the actual design of the 744 system does exactly this: it tunes into another station than the one with the given identifier, because it has no means to do the right thing (whatever that is). And indeed, the result is that even with this database tuning system, pilots still must morse-identify the station before relying on it. And apparently, the chance of a false morse decode producing the entered ID is considered remote, so if the decoded ID agrees, there is no requirement for aural ID.

So I don't doubt your standards -- I just pointed out that there is equipment out there which mistunes after you give it an ID.

And we all assume, because of this, that the ID shown on the CDU (the ID to be looked up and converted to frequency) will in certain circumstances not equal the decoded ID shown on the ND.

We also assume that first the ND shows the frequency, as it only gets data from the radio, not from the CDU. When the radio has decoded the morse, it sends the result to the ND, and the ND replaces the frequency with the ID.

Apparently there is no check built in between the given CDU ID and the decoded received ID, possibly because the pilots are required to check it anyway, and also because the auto-decoder may not be as reliable as you want it to be to drive an EICAS caution message of some kind.

Jeroen

[Zinger]

Thanks Jeroen,
I wrote about this error in my follow-on comment (#14 item 2.), quoting the B744 Ops manual.