# Hammerhead/Integrators

Jump to: navigation, search

The integrators are perhaps the key to the hammerhead chip.

 NOTE: I'm unhappy with the term input bit but can't think of another logical term. The other terms are standard

The GPS signal comprises several levels. First there is the carrier, at 1.2Ghz(?) which is multiplied by the 1024 element long spreading code - the PRN, which varies per satellite, at a chip rate of 1.024Mhz, leading to a input bit rate of 1Khz.

Then the navigation messages are modulated onto these input bits at a rate of 50Hz, so a navigation bit comprises 20 input bits.

There must be several integrators to track the GPS signal, while meeting the observed packet transfer statistics.

As there are no periodic transfers at 1Khz from each satellite, or even 50Hz, it must somehow store the navigation message bits and send them on when requested.

Exactly how 'cooked' this is is an interesting question.

There must fundamentally be several layers.

First there are massively parallel correlators, which read the relative timing between a local clock and the begining of each input bit by correlating the incoming signal from each satelite, with a locally generated copy of the PRN.

This must output into 2048 bins. (1024 with an I and Q - 0 and 90 degree shifted output each)

The input bit rate from the output of the correlators at 1ms is not however the data bits as desired for the lower levels - each navigation bit is 20 input bits'.

There must be some way of synchronising the alignment (perhaps in software, perhaps in hardware) of the navigation bits with the bit-edges of the input bits.

This is considerably simpler than the first correlator problem, but there still could be several ways it is done.

This integrator allows the navigation bits to be assembled automatically into segments of navigation messages. These must then be downloaded in some form by the software.

There is however another complication.

Simply looking at the peak of maximum energy of the spreading code correlator will get you a psuedorange accurate to around a microsecond, or 300m.

In order to get 1m of error due to this source, the I and Q measurement in the spreading code correlator would have to be measured to a little worse than a degree.

This is probably not possible.

One method of solving this would be to have several bins in the correlator not correlating between an integer position in the spreading code and the incoming signal, but at very small offsets - +5 and -5 degrees, for example, which will help when the hammerhead is adjusted to exactly the right doppler to track the satellite, and the phase is trimmed so that it's aligned as closely as possible.

On reflection, is this required. Perhaps long enough integration and accurate tracking can produce an accurate enough signal without this. Another question is do the +-5 degree correlators - if present - get any meaningful signal.

##### Personal tools

The integrators are perhaps the key to the hammerhead chip.

 NOTE: I'm unhappy with the term input bit but can't think of another logical term. The other terms are standard

The GPS signal comprises several levels. First there is the carrier, at 1.2Ghz(?) which is multiplied by the 1024 element long spreading code - the PRN, which varies per satellite, at a chip rate of 1.024Mhz, leading to a input bit rate of 1Khz.

Then the navigation messages are modulated onto these input bits at a rate of 50Hz, so a navigation bit comprises 20 input bits.

There must be several integrators to track the GPS signal, while meeting the observed packet transfer statistics.

As there are no periodic transfers at 1Khz from each satellite, or even 50Hz, it must somehow store the navigation message bits and send them on when requested.

Exactly how 'cooked' this is is an interesting question.

There must fundamentally be several layers.

First there are massively parallel correlators, which read the relative timing between a local clock and the begining of each input bit by correlating the incoming signal from each satelite, with a locally generated copy of the PRN.

This must output into 2048 bins. (1024 with an I and Q - 0 and 90 degree shifted output each)

The input bit rate from the output of the correlators at 1ms is not however the data bits as desired for the lower levels - each navigation bit is 20 input bits'.

There must be some way of synchronising the alignment (perhaps in software, perhaps in hardware) of the navigation bits with the bit-edges of the input bits.

This is considerably simpler than the first correlator problem, but there still could be several ways it is done.

This integrator allows the navigation bits to be assembled automatically into segments of navigation messages. These must then be downloaded in some form by the software.

There is however another complication.

Simply looking at the peak of maximum energy of the spreading code correlator will get you a psuedorange accurate to around a microsecond, or 300m.

In order to get 1m of error due to this source, the I and Q measurement in the spreading code correlator would have to be measured to a little worse than a degree.

This is probably not possible.

One method of solving this would be to have several bins in the correlator not correlating between an integer position in the spreading code and the incoming signal, but at very small offsets - +5 and -5 degrees, for example, which will help when the hammerhead is adjusted to exactly the right doppler to track the satellite, and the phase is trimmed so that it's aligned as closely as possible.

On reflection, is this required. Perhaps long enough integration and accurate tracking can produce an accurate enough signal without this. Another question is do the +-5 degree correlators - if present - get any meaningful signal.