View source for Hammerhead/Integrators

From Openmoko

Jump to: navigation, search

You do not have permission to edit this page, for the following reasons:

  • The action you have requested is limited to users in the group: Administrators.
  • You must confirm your email address before editing pages. Please set and validate your email address through your user preferences.

You can view and copy the source of this page:

Return to Hammerhead/Integrators.

Personal tools

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