Over the weekend I wrote some simple acquisition code. The method is rather simple, but effective.

The +/-5kHz band is 31 evenly spaced local oscillators - each 330 Hz apart. At any given time, one Space Vehicle is being searched for, over all 31 frequencies. Each of 1023 phase alignments is tested for 2ms, and each test is offset by 1us from the last one. When a 'sniff' of a signal is received, a channel is assigned to it and it tries to achieve lock. If a better 'sniff' is seen, the channel is reset with the new values, and once again tries to achieve lock.

The scheduling of which SV is being acquired changes depending on if lock is achieved, if any 'sniffs' were found, and an initial setting of priorities from a text file. At the moment, this uses about 15% of a CPU Core (out of a current total of around 30%).

One problem was that when a channel starts to lock, it can fall one of two ways - either onto the correct frequency (yay!) or fall to 500Hz to one side (wah!). If it falls to one side the channel's in-phase value alternates between + and - every millisecond, rather than staying steady for 20ms. My fix for this was when you have half a second of bad NAV data, but still have a signal lock then adjust the NCO by 500 Hz, towards (and past) the initial frequency. This jumps the channel pretty much directly into lock.

All in all the results have been pretty good: - It has been able to tease out 8 channels from a test data set:

Update at  195.000    Acquiring 29
Channel status:
SV, WeekNum, FrameOfWeek,     msOfFrame,  earlyPwr, promptPwr,   latePwr, frame, bitErrors
23,    1942,       38729,  2001.1655120,     89461,   1110140,    125161,  12345       0
03,    1942,       92342,  2007.5771226,    271183,   4084861,    152405,  12345       0
14,    1942,       92342,  2006.9831913,    169201,   3817052,    223213,  12345       0
26,    1942,       92342,  2005.1505016,    131473,   2327256,    141497,  12345       0
31,    1942,       92342,  2010.4623747,    303547,   6850993,    251145,  12345       0
04,    1942,       92342,  2006.0406834,    134309,   3619075,    157964,  12345       0
22,    1942,       92342,  2010.4915444,    110075,   6369297,    146286,  12345       0
16,    1942,       92342,  1999.1110117,    123204,    988464,     62537,  12345       0



Space Vehicle Positions:   BAD TIME DETECTED - SV position dropped
sv,            x,            y,            z,            t
23, -10332457.50,  13443819.33, -20441422.71, 554054.00768279
 3, -10332457.50,  13443819.33, -20441422.71, 554054.00768279
14, -16698154.35, -12949614.61, -15924944.22, 554054.00704834
26, -25841408.28,  -4860111.89,  -4072673.60, 554054.00566661
31, -15305881.89,  -4074165.08, -21307244.57, 554054.01025238
 4, -24522414.32,  -7782155.47,  -7385698.32, 554054.00603940
22, -18729989.63,  10711501.63, -15288354.25, 554054.01043638


Solution ECEF:  -4582619.86,    609345.20,  -4379474.77,     0.00394
Solution LLA:     -43.64293,    172.42588,        10.66

Next effort will be to work out how to better keep the NAV bit message alignment in the presence of data errors (the cause of the "BAD TIME" for SV 32)...