Mode S code 000000 !

[ianmalc]

I have picked up this 000000 code twice in the last week here in southend.
I think it may be a helicopter using callsign Dubai 139 .

Ian

[Manuel Mendes]

More squawk codes for 000000:

2554
0602
1507
4615
3245
4127
0250

[freqhopping]

I get this often and I'm in the United States. I also get 000001 and I think squawk codes change on that one too.

At times it seemed liked it coincided with a US Customs helo that wasn't using it's assigned mode-s code. The altitude displayed tended to match the helo's.

[Roadrunner]

There is the possibility that the latest software upgrade and allowing ANRB to be to the same level of reception and individual flights as SBS1 that these "ghost" codes will become a feature of the ANRB as they have been on the other device. I get these codes on a daily basis but they normally start and fin ish at the same time, although sometimes the finish time is earlier than the start time :-). They are possibly internally generated by the reciever, just like the Birdies that can be received on Airband radios ?

Mike

[DaveReid]

There is the possibility that the latest software upgrade and allowing ANRB to be to the same level of reception and individual flights as SBS1 that these "ghost" codes will become a feature of the ANRB as they have been on the other device. I get these codes on a daily basis but they normally start and fin ish at the same time, although sometimes the finish time is earlier than the start time :-). They are possibly internally generated by the reciever, just like the Birdies that can be received on Airband radios ?

Everything we see on our screens is derived from a 56-bit or 112-bit packet radio transmission from the aircraft.  Like any transmission, it's subject to distortion and interference, and since 24 of those 56/112 bits represent the aircraft's Mode S address, there's a reasonable probability that invalid addresses will be decoded from time to time.

Presumably both RadarBox and SBS have ways of trying to detect and filter out these invalid codes (bearing in mind that it's unlikely that the same corrupted address will be picked up more than once) but it seems likely that a few will slip through the net, and those are presumably the ghost codes that we see on our screens.

I don't think there is any solution for this.

[tarbat]

Is there not parity checking on the messages?

1. Short Squitter (56 bits):
   8 bit control
   24 bit aircraft address
   24 bit parity

2. Extended Squitter (112 bits):
   8 bit control
   24 bit aircraft address
   56 bit ADS message
   24 bit parity

Shouldn't both SBS-1 and Radarbox check parity to avoid these types of error?

Parity check (PI field): This 24 bit field is an error detection code to help a receiver determine errors in the received message - from http://elearning.eurocontrol.int/ATMTraining/PreCourse/SUR/ADS/Taste%20the%20Course/32501.10.32657.85.28722/Default.html

The 24 bit PI field is generated by a polynomial division of the Mode S message by a fixed 24 bit polynomial. The PI field is used for detecting bit errors and may also be used for correcting bit errors in the message.

[DaveReid]

The PI field is defined as Parity/Interrogation Identifier, and appears in the DF11 (All-Call Reply) and DF17 (Extended Squitter).

It consists of the parity bits overlaid with the interrogating radar's identity code.  RadarBox/SBS has no way of knowing the latter and it follows that the PI field can't therefore be used for error detection in DF11s and DF17s.

See ICAO Annex 10, Volume IV, para 3.1.2.3.2.1.4.

[tarbat]

Thanks for that explanation Dave.  I've struggled for a while to understand why the parity field in both the short and extended squitters can't be used to detect these types of error.  As you say, since Radarbox doesn't know the radar's identity code, parity checking is not possible.

If its not even present in DF20 and DF21 messages, that would explain why we're seeing incorrect Flight IDs on some non-ADS/B aircraft now, normally explained by just a one bit error in the ModeS code.

In fact, I'm suprised we don't see more erroneous data!!

[DaveReid]

If its not even present in DF20 and DF21 messages, that would explain why we're seeing incorrect Flight IDs on some non-ADS/B aircraft now, normally explained by just a one bit error in the ModeS code.

You'll get used to it  :-)

And don't forget that bit errors in the DF4/20 and DF5/21 can also produce altitude and squawk errors, respectively !

[AirNav Support]

Indeed thats why in those rare occasions you see helis or none pressured aircraft at concorde levels.

[GreekSpy2001]

Post in correct thread

Have  hex 000001 flight id of "x hop g" showing at 16000 ft sqk of 1104

Graham

[CoastGuardJon]

Indeed thats why in those rare occasions you see helis or none pressured aircraft at Concorde levels.

I wondered why in the James May "Edge of Space" programme recently, so much fuss was being made about the total dependence on Astronaut type suits, when Concorde had been flying at 60,000 feet and higher, carrying passengers without these fancy suits.    Although I never had the pleasure/privilege of flying in Concorde, it was regularly commented on, that the thin layer of atmosphere James was taken up in the TR1 (not really a U2!) was clearly visible to fare-paying passengers

[Allocator]

You are assuming that the U2/TR1 only goes up to 70,000 ft as shown on TV.

On the Jonathan Ross show on Friday, James May happened to mention that it was quite OK to say that he flew at 70,000 ft, but that if he said that he'd flown any higher it would be classified information.

[CoastGuardJon]

You are assuming that the U2/TR1 only goes up to 70,000 ft as shown on TV.

Hi Allocator, that's a negative, 86,000' U2/TR1, and 90,000' for SR71!, and Concorde flown to 67,000', although 60,000' was her usual cruising height, if I remember correctly........................

[malc41]

From the info I have those figures are right.