Generating GPS-style Gold codes

Mark_T

From what I understand Gold codes are sets of equal length pseudo-random bit patterns that have low cross-correlation between any pair of distinct codes from the set. Or more importantly a guaranteed bound on the maximum cross-correlation between any two codes.

This makes them useful for communications as different codes can share a channel. For instance the GPS system uses Gold codes for the navigation data-stream,
each satellite using a different code. And these are documented.

There are two LSFRs of ten bits each (thus each has a 1023 cycle length). The two are combined (XORed) with different relative phases to generate different
codes. The phase offset is done by picking 1 fixed tap from the first LFSR and 2 variable taps from the 2nd - changing the variable tap points has the
effect of shifting the pattern.

In PASM I've brought this down to 5 instructions, due to the handy parity function of the carry flag in the TEST instruction and MUXC. Both LFSRs are
in the same register so the shift is shared and a single TEST instruction can combine the 3 output taps in one instruction:

step_lfsrs
		test	val, H03A6_0000  wc  ' feedback taps for G2
		muxc	val, H0000_8000      ' inject ready for the left shift
		test	val, H0000_0204  wc  ' feedback taps for G1
		rcl	val, #1              ' inject at LSB as well as shift both LFSRs
		test	val, selector  wc    ' XOR the three output taps to put output bit in C flag
step_lfsrs_ret	ret

H0000_0204	long	$0000_0204      ' G1 poly
H0000_8000	long	$0000_8000      ' inject point for top 16 bits (RCL used for G1)
H03A6_0000	long	$03A6_0000  ' G2 poly in top 16 bits
selector	long	$0022_0200  ' combine taps for G2 with G1's output

I found information on these sites valuable: https://archive.org/details/ADiyReceiverForGpsAndGlonassSatellites, https://natronics.github.io/blag/2014/gps-prn/

I continue to marvel at how PASM can capture quite complex pieces of hardware in a few carefully chosed instructions, I thought this was a good example.

Mark_T

PS the value of selector would be changed for a different code - here its the first one if the list with tap offsets 2, 6 (corresponding to bits 1 and 5 in a zero-based world).

I've been experimenting generating spread-spectrum signals (see other post of mine) using this to setup my
chip-tables. Even with 5 ASM instructions its not fast enough to feed bits out at the 5MHz I want so I store
the 1023 bits in 32 longs in the cog at start up, passing in the selector value. Pushing out 32 chips at a time
with WAITVID gives lots of time to modulate the signal, but generating the bits on the fly doesn't seem possible at
more than about 2.5MHz

KeithE

Interesting project.

The GPS L1 C/A gold codes are pretty clever since they can be implemented with a trivial amount of hardware (think 1970's technology) and have pretty good properties. Talking about having to store the codes to get speed - for fun check out the Galileo "memory" codes which were developed with genetic algorithms. There are no equations, just predetermined codes that you have to store.

Phil Pilgrim (PhiPi)

This is getting interesting! I did something similar using Walsh functions -- albeit on a much smaller scale -- here:

http://forums.parallax.com/discussion/146879/one-sensor-to-discriminate-walsh-modulated-ireds

It was made easy, since the transmitting and receiving were done in the same micro, so I didn't have to worry about phase locking.

-Phil

Mark_T

Yes, that is helpful - I've been putting off worrying about signal acquisition / phase locking until I've figured out
how I'm going to transmit (baseband with LED perhaps, having seen your Walsh function demo)
and how to mix/demodulate on receive side

KeithE

You probably know this, but if you test both transmit and receive then make sure that you start debugging with the transmitter and receiver running from the same clock. You'll have to figure out how sensitive your system is to clock error and plan accordingly when the transmitter and receiver are using different clock sources.

e.g. see page 36 in the book preview here for how this works with GPS:

https://www.amazon.com/GPS-Assisted-GPS-GNSS-SBAS/dp/1596933747

Sorry I couldn't find a better reference right now.