[time-nuts] GPS jamming susceptibility

[Magnus Danielson]

On 23/11/10 16:12, jimlux wrote:
> scmcgrath at gmail.com wrote:
>> The Phrack article's jammer attacks the offset frequencies.
>>
>> Phrack.org/issues.html?issue=60&id=13
>>
>> This article shows just how vulnerable L1 GPS is
>>
>
> I'm not very impressed by design...
> That old Freescale/Motorola MC145151 PLL, and using a separate
> prescaler? That's a 1970s-1980s design out of some old ap note. Can you
> even buy a 145151 anymore? I suppose you can, there's probably millions
> of them out there in all manner of radios.
>
> Why not get an eval board for one of the plethora of MMIC PLLs out there
> that has VCO, dividers, etc. all on one die. Heck, NS has a whole
> webbench application that will basically design the thing for you.
>
>
> On a related note... What about a GPS signal simulator.. Yes, there are
> commercial vendors out there who will be happy to sell you one for many
> tens of $k.. how about something simpler? Seems it should be easy to
> have a FPGA programmed up to generate all the PN codes and nav messages,
> and just run it out to a mixer with a 1575 MHz LO (generated by one of
> the aforementioned $100 NatSemi eval boards)..

Should not be impossible.

> Or is it too much of a pain to do the doppler? That would take something
> like an DDS to create a reference for each S/V simulator, with the DDS
> programmed for the required doppler. So it would take N channels to do N
> S/Vs in view. Yeah... the multi $10k starts to seem reasonable now..

It would not be too expensive actually. Just as you do N channels of 
PN-code generation you do N channels of doppler carrier and chip-rate 
DDS within the FPGA. One needs some form of doppler calculator that 
updates the doppler offsets in real-time and then you would need some 
application cooking up N channels of NAV-data, but it should not be 
prohibitively expensive. Adding things like multi-path simulation on a 
per channel basis is more expensive, as it would be a bunch of FIR taps 
spread out and in need of updates. Also would a filter for ionospheric 
and tropospheric simulation be needed, which parmeters also needs 
changes as time goes by... and some added thermal noise unless the 
noise-level of the system does not match up with reality. :)

> I was sort of hoping, in the back of my mind, that some grad student out
> there had created some FPGA code to run on a Xilinx eval board (or a USRP2)

It's not that different from a FPGA based receiver.

Cheers,
Magnus