GPS Free Stack/Notes About Namuru

Acknowledgments

Sampling

Accumulator interrupt signal need to be read (polling STATUS bit 1) or managed by CPU/ISR in 
order to read accumulators before they get overwrite.

Accumulators provides correlation results that can lately be interpreted/tracked to extract chips/bits once signal peak is confirmed trough acquisition.

Timing

Accumulator interrupt is asserted high according to ACCUM_COUNT value:

The Accumulator interrupt signal and flag needs to have 
between 0.5 ms and about 1 ms period.
This is to ensure that accumulation data can be read
before it is written over by new data.
The accumulators are asynchronous to each other and have a
dump period of nominally 1ms.

ACCUM_INT period = (accum_divide + 1) / 16.384MHz For 0.5 ms accumulator interrupt accum_divide = 16.384x10^6 * 0.0005 - 1 accum_divide = 0x1FFF

Accumulator interrupt MUST be asserted low after status read bit from CLEAR_STATUS register is set high.

TIC allows to sync measurements across all channels, PROG_TIC register control measurement period. 

tic period = (tic_divide + 1) * Clk period If clocked by SiGE 4162 Realmode 16.384Mhz : tic period = (tic_divide + 1) / 16.384 Mhz For default tic period (0.1s) tic_divide = 0x18ffff

Channel tracking

Namuru core needs to initialize first the time-base logic, which will provide clock sampling for correlators and accumulators and a software driven interrupt which means that int it only get triggered if certain registers are enabling do it so and after triggered it also need to be cleared

Accumulator interrupt must be enable by STATUS bit 0 tic, bit 1

Both TIC and Accumulator interrupt down counters can be read (may be to predict or time measurement??)

Tracking channels need to be initialized as well:

1. loading PRN valid value
2. loading carrier NCO value initial value
3. loading code NCO value
4. loading code slew value
5. enabling tracking channel logic (epoch, slew, prn)

reset after write???? NO at same time, thi

if prn enable is logic high shifter/counter is cleared

if prn enable is logic low code generator operates (prn code generator have a shifter with no enable)

Acquisition loop First we need to be certain of both noise floor threshold and signal peak, so we can proceed to tracking Artyom from gnss-sd.ru suggest the next debug procedure:

• Choose a satellite that is definitely visible. (gpredict simulate this) Set it's prn number. Set code_reference_frequency to default value (2.046MHz). Set carrier_frequency to zero Doppler
• Then pass through all delays and record values in memory. After that set next Doppler frequency. And repeat. This way pass through all Doppler frequencies. By carrier_nco register.
• Doppler frequency step can be 1000 Hz
• Delay step can be 1 or two half-chips
• Finally move all values from memory to the file and plot the result
• You should see one peak in the scatter plot
• This can help you to check what is your noise floor and what is your peak maximum.

Doppler affects also code_nco but this affect is negligible code_nco works with double chip rate (2*1.023 MHz) (confirm??)

Registers

Channel related registers

Register	Address	Description
CH0_PRN_KEY	(0x00)	Gold code sequence
CH0_CARRIER_NCO	(0x04)	Local carrier oscilator frequency control
CH0_CODE_NCO	(0x08)	Local C/A code oscilator frequency control
CH0_CODE_SLEW	(0x0c)	C/A code delay control
CH0_I_EARLY	(0x10)	I Early Accumulator
CH0_Q_EARLY	(0x14)	Q Early Accumulator
CH0_I_PROMPT	(0x18)	I Prompt Accumulator
CH0_Q_PROMPT	(0x1c)	Q Prompt Accumulator
CH0_I_LATE	(0x20)	I Late Accumulator
CH0_Q_LATE	(0x24)	Q Late Accumulator
CH0_CARRIER_MEASUREMENT	(0x28)	Carrier cycle count and phase since last TIC
CH0_CODE_MEASUREMENT	(0x2c)	Code measurement (code half-chip, code NCO phase)
CH0_EPOCH	(0x30)	C/A code count latched on TIC
CH0_EPOCH_CHECK	(0x34)	same as EPOCH but no latched to TIC
CH0_EPOCH_LOAD	(0x38)	Modify epoch counter

Status

STATUS	(0x380)	bit 0 TIC occurred, bit 1 accumulator int, need to be clean manually after read (cleared after read)
NEW_DATA	(0x384)	data dump one bit per channel (cleared after read)
TIC_COUNT	(0x388)	Provides TIC down counter value
ACCUM_COUNT	(0x38c)	Provides ACCUM INT down counter value
CLEAR_STATUS	(0x390)	Clear STATUS flags (need to be cleared)
HW_ID	(0x3bc)

Control (Mostly time-base related)

RESET	(0x3c0)	Software reset
PROG_TIC	(0x3c4)	Control TIC period value for down counter
PROG_ACCUM_INT	(0x3c8)	Control ACCUM INT period (must be less 1 ms)

Notes from Artyom (gnss-sdr.ru project), clarifying acquisition and tracking

First of all: for acquisition and tracking you don't have to know anything about ephemeris or almanac (So we cam implement a separate this layer from fix)

Every receiver has a "cold" mode. In this mode it has no information about ephemeris or almanac. (And i warm mode we assume that recent ephemeris or almanac) So in this case you have to pass through all combination of delay/doppler_shift for each satellite When acquisition success for some combination delay/doppler_shift for some PRN (or some satellite in other words) then confirmation starts. If confirmation is also success then tracking starts to work

During tracking you can take output from in-phase_promt correlator arm this I_prompt output is your navigation data The only thing that you must remember is that each bit lasts 20 ms or 20 I_prompt outputs so you have to make some additional steps to synchronize with 20ms-bits edges.

Slew control is done only during acquisition when tracking starts there is no need in additional slew control Everything is done by Delay Lock Loop which control chip-rate And the change in chip rate is equivalent to slew-control. But chip rate control is much more precious than slew control.

(chip rate is not constant because Doppler )

Let's forget for some time about data-bits... You can forget about them. Let's speak only about tracking

Tracking consists of two parts For simple receivers (like ours) these parts are independent One part of tracking is to follow carrier. This is done by adjusting carrier_NCO_frequency We take output from correlator (two PROMPT outputs) and calculate (osgps firmware) the difference in frequency (or also phase) between our local NCO_carrier and the received signal So this is how carrier tracking is working.

We always have to control carrier because satellite is always moving with some acceleration so there is always some change in doppler

And now the same explanation about code-tracking We have to track code because of the same reason: satellite is always moving! Because the change in chip rate due to Doppler is very little for code-frequency (but it exists!) we have to control code position very preciously This precious control can not be done by slew rate (because slew allows us only to shit for half a chip - too much for our task)

You should not split "bit edges' and "chip rate" bits length depends on the current chip rate the idea of code tracking is absolutely the same as for carrier tracking The only difference is how to calculate difference between locally generated signal and satellite signal that difference is calculate by osgps and is fast.