Time delays

[Allocator]

Hmmmm...... that's interesting, hadn't considered that.

However, I'm not seeing any odd transitions between my live flights and real-time Network tracks.

Surely, the  level transmitted by the aircraft transponder is based on 1013 so the source data will always be correct.

Unless it is altered by the QNH setting as in Preferences and I'd have thought that this takes place locally - on the display PC.

[tarbat]

Surely, everything is based on 1013 as this is what is transmitted by the aircraft, unless it is altered by the QNH setting and I'd have thought that this takes place locally - on the display PC.

Well, that would cause problems as well.  I set QNH based on that at Inverness.  If that was then applied to aircraft I see on the real-time network landing at Heathrow, for example, then it would be wrong.

Airnav, can you explain how TA/QNH settings are used for network aircraft.

[Allocator]

Yes it would be wrong for Heathrow but not for Inverness.  QNH will be different for both airfields.  That's why QNH is passed with the weather and set by the pilot before making an approach.

[Fenris]

I can say without any doubt there is no delay, certainly not a 2 minute delay.

Presumably, and I don't know exactly the relationship between the network indicator and the actual displayed aircraft on the map, there must be a 20 second delay as the current data won't be received until the next refresh?

[DaveReid]

Airnav, can you explain how TA/QNH settings are used for network aircraft.

Yes, now would be an opportune moment for AirNav to explain how this works.

And preferably not a response starting with "I think ..."  :-)

[AirNav Support]

QNH difference is not applied to network aircraft being uploaded nor when downloaded. Unless a bug has crept in :)

[tarbat]

So altitude will be based on 1013 for network aircraft.  In that case it may well be different to the altitude reported by the pilot below 5000ft.  That would explain Jeremy's initial observation.

[Jeremy]

I was talking about the Real-time network and you theory is an interesting one!
Please - I am not moaning - it is just an observation and an interesting discussion!
J.

[Deadcalm]

Are we absolutely certain that "real time" is exactly that, and not that there's still some sort of delay (inbuilt or otherwise)?

DC

[Allocator]

As I said earlier, watching and listening I can't see any delay.  I do however accept that that the 20 second update rate by it's very nature can result in a 20 second 'delay' depending on processing.

Little different to controlling using a 15 rpm radar - this gives you a 'delay' of 5 seconds i.e. the time between radar sweeps.  Hence the 'anticipation' required when controlling - almost insignificant, but finite none the less.

[Jeremy]

Morning all!
Nice discussion. Descent rate of 800ft/min is roughly equates to 250ft over the 20 sec delay. Plus PC processing time. Plus server processing time. Plus QNH and we are not far off. I will follow this again over the weekend if I get a chance.
Thanks chaps.
J.

[bratters]

This is the sort of stuff forums are for!

[DaveReid]

Little different to controlling using a 15 rpm radar - this gives you a 'delay' of 5 seconds

Is that based on the standard NATS/RAF 75-second minute ?  :-)

[Allocator]

AR1, AR15 and Watchman as far as I remember.  Can't recall the Cossor 787 rpm.

Of course, with a fully processed digital pictures these days, this is not as noticeable.

Then there were the FC radars with a 4 rpm update being used offset by 200 nm or so - ha!