I wonder if anybody has correlated the difference in time to what you hear a/c report on VHF and what you see in Real-time? I have followed a/c into Gatwick and hear them report height and speed. By working out the difference against what I see, taking vertical descent rate, there seems to be a 2 minute delay. Anybody else worked it out?
No compalint - just interested.
J.
Quote from: Jeremy on October 08, 2009, 03:24:11 PM
I wonder if anybody has correlated the difference in time to what you hear a/c report on VHF and what you see in Real-time? I have followed a/c into Gatwick and hear them report height and speed. By working out the difference against what I see, taking vertical descent rate, there seems to be a 2 minute delay. Anybody else worked it out?
No compalint - just interested.
ADS-B-equipped aircraft transmit their position twice per second. AFAIK, it takes the same time for the ADS-B signal to reach your RadarBox as it does for the VHF transmission to reach your scanner, so I have no idea where a 2-minute delay would arise from.
Maybe Jeremy is talking about aircraft on the real-time network? I've certainly never seen a delay on locally received aircraft - and I've sat at the end of the runway at EGPE and observed landings on Radarbox.
I got the impression Jeremy was talking about Airband - not RB.
Quote " difference in time to what you hear a/c report on VHF and what you see in Real-time? Unquote
?????
For clarification - VHF audio v Real-Time network. The network updates every 20 secs but I am seeing a delay of 2 mins approx.
J.
I guess the answer would be to set up two RBs side by side, one on Myflights and the other on Network, together with a visual of the aircraft itself.
That experiment should be definitive.
OK, now we know what two sources we're comparing.
Comparing reported heights with Mode S height readouts isn't as straightforward as it sounds as below the TA the former will be based on QNH and the latter on 10132.mb. Depending on the QNH on the day, the difference could easily be plus or minus 1000ft.
A better comparison would be ADS-B position from the real-time network vs a Mark 1 eyeball sighting. Any volunteers ?
Good answer.
J.
Being about 5 miles from Heathow, I'm in a very dense traffic area and have ample opportunity to watch the real-time data and monitor the London TMA and Heathrow Director frequencies, and I can say without any doubt there is no delay, certainly not a 2 minute delay. Levels for the hold, heading for leaving the hold, vectors onto final approach and distance to run as passed by ATC are all 100% real-time.
Even when controlling. you are aware that what you are seeing is 'history' and you make an allowance for this. A typical example is recovering 'no compass no giro' aircraft that depend on you for starting and stopping the turns. The skill is in the anticipation of those turns and if you wait to see the effect before stopping the turn, you are already too late.
I suspect that this is the 'delay' that you think you are seeing :-)
"Adopt the no compass no giro procedure, make all turns rate one, stop and start your turns on the executive word now, is this a practice?"
Ahh! it seems like only yesterday!
Quote from: Allocator on October 08, 2009, 07:00:11 PM
Being about 5 miles from Heathow, I'm in a very dense traffic area and have ample opportunity to watch the real-time data and monitor the London TMA and Heathrow Director frequencies, and I can say without any doubt there is no delay, certainly not a 2 minute delay. Levels for the hold, heading for leaving the hold, vectors onto final approach and distance to run as passed by ATC are all 100% real-time.
That's very reassuring for those of us undecided about subscribing.
I would doubt they would anticipate height and speed. I think the QNH is more likely to be the delay. I am talking about out at about 5,000 ft.
It is interesting that I hear them well on VHF but struggle on 1.2 Ghz, hence using the network. The aerials are at the same height and about 20ft apart. Could be feeder loss and polor diagram of the antenna.
J.
Quote from: Jeremy on October 08, 2009, 07:24:26 PM
I would doubt they would anticipate height and speed. I think the QNH is more likely to be the delay. I am talking about out at about 5,000 ft.
It is interesting that I hear them well on VHF but struggle on 1.2 Ghz, hence using the network. The aerials are at the same height and about 20ft apart. Could be feeder loss and polor diagram of the antenna.
J.
If you are seeing a 5000ft difference in what the pilot is reporting and what you are seeing on the map screen, then you definitely have a problem. Above the level you have set in Preferences, everything will be related to Flight Level i.e. relative to 1013 mb. Below the Preferences level, the altitude will be relative to QNH which changes with the weather.
Have to entered an airport in the SmartView tab and selected the 'Auto set QNH' tick box?
You miss read my last. Descending, at around 5Kft as they approach to land.
I will try auto set QNH.
J.
OK Jeremy, you meant that there was an error at about 5000 ft, not an error of 5000 ft?
Note the settings below as in Preferences. In my case, above 6000 ft, heights will be shown as Flight Levels - altitude relative to the Standard Altimeter Setting of 1013.2 mb
Below this level, altitudes will be based on QHN - sea level pressure.
http://en.wikipedia.org/wiki/Flight_level
Quote from: Jeremy on October 08, 2009, 09:05:57 PMI will try auto set QNH.
Surely the auto-set QNH will only affect locally received aircraft. I thought we were discussing aircraft on the real-time network. I would guess that the altitude of these network aircraft would depend on the TA and QNH set on the PC receiving the signal before it's uploaded to the Airnav server.
If the receiving PC has a bad QNH, or TA set at FL00, for example, then the altitude will be wrong.
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.
Quote from: Allocator on October 08, 2009, 09:32:32 PMSurely, 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.
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.
Quote from: Allocator on October 08, 2009, 07:00:11 PM
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?
Quote from: tarbat on October 08, 2009, 09:34:34 PM
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 ..." :-)
QNH difference is not applied to network aircraft being uploaded nor when downloaded. Unless a bug has crept in :)
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.
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.
Are we absolutely certain that "real time" is exactly that, and not that there's still some sort of delay (inbuilt or otherwise)?
DC
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.
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.
This is the sort of stuff forums are for!
Quote from: Allocator on October 09, 2009, 08:21:55 AMLittle 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 ? :-)
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!