Inertial position conversion

A first glance onto trial data

Receiver clock synchronization

A first glance onto trial data is available here.

The receiver clock synchronization values have been determined here.

TDOA calculation software underway of being prepared using this

Introduction

What do we miss from our beloved SBS-1?

The aircraft list is cluttered with flights that do not appear as a radar target. These are mainly older aircraft like the MD80 series, but also modern Regional Jets (CRJ, Embraer) and the fast growing crowd of light type aircraft lack the position ADS-B squitter that is required to show them as a radar target. Not to forget military flights that tend to hide their position.

While ADS-B radar position accuracy can be as good as a few meters when GPS is used or as bad as 5NM when the aircraft's IRS is used, we cannot see those "no-pos" flights at all. Making them visible and bringing the deptiction accuracy into the range of a position squittered flight is the task of this trial.

Compared to trials that have been run by others this trial uses a highly scientifc calculation scheme that requires four or more receivers to "see" the same no-pos flight. More about the underlying algorithm can be found here and later during the trial.

What is missed to make this all happen?

There are two very basic issues that need to be resolved for us as SBS-1 users

a) - calculation of the position of the no-pos flight

b) - display of the position as a target on the radar screen, i.e. Basestation or Planeplotter etc.

We will start with question a) and come back to question b) once we have seen results that can be used for display purposes.

Calculating the position of a no-pos flight

This is not an easy task. We will use the best available technique for this purpose that is called Multilateration. This techniques is used in professional ATC systems, too, but under much "easier" circumstances. In general it calculates the position from a set of time differences that are derived when the associated set of receivers "sees" a data signal.

Time difference of arrival (TDOA)

When a no-pos flight emits a Mode-S data signal it (the signal) travels through the atmosphere and towards its receivers with the speed of light in air (approximately, but fair enough for our purpose): 

V_LS = c / r_AIR= 299,552,815 m/s = 300 * 10⁶ m/s = 300 m / µs

This says that the data packet travels 300 m or about 1000 ft within a microsecond. If we can get a result like this we are pretty much within the accuracy area we would be happy about. If the receivers have a common time reference the thing would work like this: There would be a measurement when the signal would arrive at each receiver. The farther away a receiver would be from the no-pos flight the later the data packet would arrive there. One of the receivers involved would be the master receiver and all times of reception would be submitted to a central server (the multilateration controller). This server installation would calculate for each pair of master to another receiver the TDOA. For four stations we would get 3 TDOA values and this is exactly what we need for our purposes.

Indeed, professional receivers work like this and so does the SBS-2M. At least it was advertised that way. The common time reference can be derived from a GPS receiver with an uncertainty of maybe a few nano- or microseconds. But our SBS-1 receiver does not have GPS capability.

Others have tried to utilize the Windows PC clock for this purpose. Not only is this clock generally unsuited to serve as a sync source (updates occur only every few 10 or 100 ms), but also is the USB data stream from the SBS-1 box to the PC interface highly asynchronous. It means that data are buffered and then sent in bulks, when either a timeout has occurred (no more data have arrived for a certain period) or a buffer is full. Also other tasks on the PC may delay processing and time stamping.

Therefore, we need a different solution. The timestamp must be attached to the data packet somewhere inside the SBS-1. At the end of our introduction we have learned that the calculation of a position of a no-pos flight is very much a question of the proper the synchronization of the clocks of the SBS-1 receivers.

The SBS-1 data stream counter

This is a delicate matter and at the center of our first trials. To learn what we try to achieve we must know a few bits about the SBS-1 data stream. We know that most of it is encrypted and only a few were able to convert it to clear data. We don't anticipate this poses a problem here. Each packet of flight data comes embedded into a very professional set of additional data, amongst these there is a 24 bit counter that is very interesting for our purposes.

Table: Typical SBS-1 data packet as decrypted. Other messagetypes than 01 (ADS-B squitter) are: 05 (short Mode-S no-pos message), 07 (long Mode-S no-pos message).

Some experiments have shown that the counter is most likely driven by a 20 MHz clock, i.e. its basic interval is 0.05 µs or 50 ns. This corresponds with half a cycle of a 40 Mhz crystal oscillator chip that can be located on the SBS-1 motherboard. We can assume that this is the main clock for the digital data processing unit. Not more than that is known about this counter but there are no indications that it is used by Basestation at all except to add additional data to the packet stream. As the counter changes quickly the encryption will then let each data packet look very differently, although the raw message may not have changed.

We do not know at what stage the clock counter value is added to the data stream, but as all our receivers have the same hardware and we are only looking for time differences we can safely assume that this is not relevant. The delay from the data reception on the front end of our SBS-1 to the addition of the value is the same for all SBS-1 and subsequently the time difference is zero and can be ignored.

The resolution of the counter applied to the speed of light Vl provides a resolution of

tl = 0.05 µs * 299.552815 m / µs = 15 m

I.e. with every step of the counter the Mode-S data signal travels 15 m, which is a quite comfortable resolution.

 But there is more tricky stuff around our counter that we have to deal with. Namely

 - it is a 24 bit counter only and as such it can take values from 0 to 2²⁴-1 = 16,777,215 only before it overflows and restarts with 0. The associated length of a full 24 bit counter period is only about 0.83886 s. This means that we cannot process time differences that are greater than 839 ms (not a big deal for the calculation itself as this equals more than 250,000 km), but we also have to provide certain measures that can unambigously identify to which counter cycle a data packet belongs. 

 - all our SBS-1 receivers have a different counter value at a specific time, we call it offset

 - all clocks of our SBS-1 receivers run at different speeds at a specific time

 - as with all crystal clocks the clock speeds of our SBS-1 receivers change over time, temperature, age and whatsoever. We call it drift. The only thing we can safely assume is that a change in speed will not occur abrupt but smoothly.

Clock synchronization with ADS-B flights

Before we can chase no-pos flights we need to know what characteristics the clock of each of our SBS-1 receiver chain has. We will declare one of our receivers the master receiver. We have learned that three values are important, the offset, the speed difference and the drift between the master and the other receivers.

To calculate these values we use a method that is probably used for the first time here and that is surprisingly simple. It makes use of those ADS-B squitters that not only carry exact position data of the transmitting flight but also the same counter value as described above for no-pos flights. Because we know the exact position of the SBS-1 receivers, too, we can calculate the distance between the target and the receiver and, after application of the rule of the speed of light, we also know what the travel time of the data packet is.

This will be our first stage of trial.