# Hammerhead/Integrators

### From Openmoko

m (tidy) |
ChrisKuethe (Talk | contribs) m |
||

Line 2: | Line 2: | ||

The GPS signal comprises several levels. | 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. | + | 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.023Mhz, leading to a '''symbol rate''' of 1Khz. |

− | Then the navigation messages are modulated onto these '''symbols''' at a rate of 50Hz, so a '''navigation bit''' | + | Then the navigation messages are modulated onto these '''symbols''' at a rate of 50Hz, so a '''navigation bit''' spans 20 '''symbols'''. |

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

## Revision as of 23:14, 27 July 2007

The integrators are perhaps the key to the hammerhead chip.

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.023Mhz, leading to a **symbol rate** of 1Khz.

Then the navigation messages are modulated onto these **symbols** at a rate of 50Hz, so a **navigation bit** spans 20 **symbols**.

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

As there are no periodic transfers at 1kbit/sec from each satellite, or even 50bit/sec, it must somehow store the navigation message bits and send them on in a batch 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 **symbol** 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 **symbol** 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 **symbols**.

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 psuedorange 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.