Map anomaly

[viking9]

Yesterday I was tracking a Gulfstream five via the network. It tracked over Scotland onto the polar track. Then the map changed to the South pole. Anyone any idea if it's an ac GPS anomaly or a problem with ANRB software?

I tried to post a screenshot but I get an error even though the file is only 48.1kb.

Tom

[Allocator]

Tom,

Do you mean that the position of the aircraft jumped?

[viking9]

Hi Allocator,

Yes, I wasn't watching it all the time, but one minute it was over Greenland, next time I looked it was over Antartica.

Tom

[tarbat]

Aircraft position anomoly.  Similar question a couple of posts earlier that I answered last night - http://www.airnavsystems.com/forum/index.php?topic=2035.msg16676#new

Or try a search on "purple rain".

[Allocator]

Tom,

See this thread regarding "Purple Rain":

http://www.airnavsystems.com/forum/index.php?topic=671.0

Because you were tracing the aircraft, you would see the map jump rather than the purple lines as the aircraft transmitted a duff position.

Not a RB problem, but an aircraft issue - some suggest done deliberately to partially conceal the position.

[tarbat]

Definately some aircraft that appear to deliberately conceal their position:
G-BUUR with position N12 00.0 E000 00.0
G-BTPF with positions N12 00.0 E000 00.0 and S42 00.0 E000 00.0

[viking9]

You could well be right as it is a known MIB ac.

Tom

[DaveReid]

Definately some aircraft that appear to deliberately conceal their position:
G-BUUR with position N12 00.0 E000 00.0
G-BTPF with positions N12 00.0 E000 00.0 and S42 00.0 E000 00.0

I find that hard to believe. 

I've logged G-BUUR and G-BTPF many times since, respectively, Oct 2006 and Nov 2007, and both as recently as this week.  Neither has ADS-B so I have no idea where those spurious coordinates originated from but they certainly didn't come from the aircraft !

[Fenris]

Definately some aircraft that appear to deliberately conceal their position:
G-BUUR with position N12 00.0 E000 00.0
G-BTPF with positions N12 00.0 E000 00.0 and S42 00.0 E000 00.0

I find that hard to believe. 

I've logged G-BUUR and G-BTPF many times since, respectively, Oct 2006 and Nov 2007, and both as recently as this week.  Neither has ADS-B so I have no idea where those spurious coordinates originated from but they certainly didn't come from the aircraft !

I don't believe there is much, if any, error correction in the MOde S transmissions.

It could be simply that a corrupted message is received that happens to appear to contain this information.

[DaveReid]

I don't believe there is much, if any, error correction in the MOde S transmissions.

It could be simply that a corrupted message is received that happens to appear to contain this information.

The Mode S spec includes a 24-bit parity string in the ACAS and ADS-B squitters, which ought to be usable by Mode S receivers, although I have no idea whether RadarBox or SBS actually make use of this.

The surveillance interrogation responses, OTOH, overlay the parity on top of the aircraft address, which means that even one mangled bit in a 56- or 112-byte packet can produce invalid data with no way that we can detect this.

[viking9]

Wouldn't just a minus in an otherwise correct latitude be enough to switch poles?

[Terry]

Here`s another strange A/C position  SPAR 76
                                                      010076
                                                      FL-68
                                                      GLF
Current position  "Middle of Antartica"?

   Regards Terry.

[Fenris]

I don't believe there is much, if any, error correction in the MOde S transmissions.

It could be simply that a corrupted message is received that happens to appear to contain this information.

The Mode S spec includes a 24-bit parity string in the ACAS and ADS-B squitters, which ought to be usable by Mode S receivers, although I have no idea whether RadarBox or SBS actually make use of this.

The surveillance interrogation responses, OTOH, overlay the parity on top of the aircraft address, which means that even one mangled bit in a 56- or 112-byte packet can produce invalid data with no way that we can detect this.

I have not looked into this much Dave, but what is the parity data protecting? Is it calculated over the whole data field, or is it partial?