[time-nuts] GNSS beam forming (was: NIST)

[Gregory Maxwell]

On Fri, Aug 31, 2018 at 2:56 PM Attila Kinali <attila at kinali.ch> wrote:
> "Just DSP work" is a tad bit more than you think. You are dealing
> with sevaral 1Msps of data, even for a simple L1 C/A receiver.
> If you are going multi-band-multi-GNSS you are usually in the 50MHz BW
> at L1 and 80MHz BW at L2/L5 range, which means you are dealing with
> something in the order of 100Msps of data per channel (either as
> a single stream of sample or two streams of samples with half rate).

I have done beamforming in software for wifi signals, which is quite
similar a task.

You are probably underestimating somewhat how fast modern systems have
become.  There are now people using GPUs for SDR now as well, which is
perhaps more fitting to a GNSS timestamper than many other SDR
applications, since that application doesn't need to be low latency.
There are now consumer GPUs that do 14 trillion single precision
multiply-adds per second.

> Then you add to it that you will need at least 4bit ADCs to get
> somewhat jaming proof, probably even 10bit or more and suddenly

There I agree.  It seems to me that a interesting architecture would
be to run a sinusoid killer on a FPGA immediately behind the DACs,
then spit out a 2 or 4 bit stream.

The best processing tool I have for estimating sinusoid parameters is
https://arxiv.org/abs/1602.05900  the computationally hungry parts
(measuring correlations with candidate sinusoids and the signal) are
easily implemented on an FPGA but still would be pretty impressive to
see running at 50msps. For GNSS applications something far stupider
probably is adequate: FFTs on windowed overlapping blocks, null out
outlying peaks and ifft.  It would not take a very large FFT to get
enough frequency selectivity to kill only 1% of signal power per
eliminated sinusoid-- maybe 256 samples.

> you are dealing with 200-400Mbyte/s data per antenna. Constantly.
> To be able to do reasonable beam forming, you probably need a 4 by 4
> grid at least, that makes 16 antennas which brings us into the

There are many papers showing interesting GNSS beamforming results
with far fewer antennas:

4 antennas, 14-bit, 40msps, and a GPU based decoder:
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3231503/pdf/sensors-11-08966.pdf

This one has simulated polar patterns for 7 antennas that look pretty
impressive https://web.stanford.edu/group/scpnt/gpslab/pubs/papers/DeLorenzo_IONGNSS_2004.pdf

This one has measurements with 7 antennas on actual hardware:
https://pdfs.semanticscholar.org/5531/aa89f81e4cdfa15e74e98c264dcb697395ca.pdf
(and also talks a bit about their SSE correlators needed to get
realtime performance in a software implementation).

> You still need the lower satellites to survey your position accurately.

Yes, but that is potentially a one time operation.

> Also, going from ~10 birds in view down to ~5 means that
> your PPS jitter just increased by a factor of 5 to 10.
> (source: experiment i've done here some time ago)

But, if your SNR on those 5 remaining birds increases substantially
from increased antenna gain might it not offset some of that loss? I
would worry that getting a consistent phase center on some weird high
gain antenna design would be hard, however.

> There is a reason why Microsemi is building more 5071 these days than
> ever before (rumors have it that they are are 3-4 devices per week).

If you consider the cost of a new 5071 ... that would pay for a heck
of a beam-forming anti-jamming receiver-- at least hardware wise. :)