On 9/27/23 8:15 AM, Lester Veenstra wrote:

It doesn't even have to be below the noise floor, since once you've
correlated it, you can coherently subtract it.  In fact, with a strong
signal, the uncertainty in your correlation is smaller, so when you do
the subtraction, you're subtracting a "more precise" copy. One catch is
that you need to recover the amplitude accurately as well as the timing,
which means you might need some additional processing, since most
acquisition and tracking codes, like for GPS, are concentrated on good
timing performance and only getting a coarse estimate of the power.

If one wants to hunting the literature, I'd look for stuff on adaptive
cancellation of interferers and jammers. Typically looking at using 2 or
more GPS antennas/receivers to null out an interference source.

If it can be of any use, Direct Signal Interference removal is implemented
as a least square optimization solution at
https://github.com/jmfriedt/passive_radar/blob/main/171210ship/goship.m#L70-L88
with ref the PRN code broadcast for timing and mes the recorded signal. This
solution was demonstrated to allow rejecting broadband GPS interference by 30 dB
but will not work well with narrowband interference (not the topic here), with no
detectable degradation of the positioning/timing capability of gnss-sdr (the
C++ implementation is in
https://github.com/oscimp/gnss-sdr-1pps/blob/master/0002-jamming.patch#L82-L129).

Hi

In this day and age, there is no absolute need to feed in something as broadband as a 1 pps edge. Yes, it is easy to just cable it “over there”. An alternative would be some sort of fairly simple phase modulated signal that is much more narrowband. Pick one you can generate with a couple chips. As you suggest, do the “correlation stuff” and come up with a very accurate time estimate of that signal. The advantage would be: You can take the “time signal” out with simple frequency domain filtering.

More or less:

Time signal runs from 8 to 12 MHz (or maybe a lot more narrowband than that ….)

Digital high pass shoves time signal “over there” and it gets processed.

Loran is < 1 MHz

Digital low pass shoves loran “over here” than then it’s processed.

No need to do the fiddly “subtract an exact image” stuff.

Yes, there are a lot of fiddly details to consider. Picking 100 KHz x 100 for your time tone carrier might not be a great idea. You would need to do a bit of work to come up with the ideal signal.

Bob

I was so impressed with this idea that I had to test it (despite this
post being over 2 years old), and I am afraid it is not as easy as it
sounds.

I started from the setup described at
http://jmfriedt.free.fr/EFTF2025_jmfriedt.pdf
where two X310 SDRs are used to record the L1 and L5 GNSS bands with
one channel, and the other channel records a 5 MHz wide PRN sequence
generated from an FPGA, demonstrating ps synchronization of the SDR
channels (having previously demonstrated that the dual channel ADC
exhibit the same drift on both channels during warmup).

To try and free some channels, I summed the GNSS antenna output
(amplified 30 dB, converted to 70 MHz IF with 7 dB loss, and amplified
20 dB at baseband) with the FPGA PRN output. The result is rather
disappointing (at least wrt my expectations): attached is the plot of
the delay estimate between X310 channels from the PRN

• when adding the GNSS antenna output (blue chart), the time transfer
  capability is degrated from a few ps to 1 ns (standard deviation).
  Both American and European GNSS constellations are decoded with
  gnss-sdr. However the GNSS C/N0 has been degraded, for e.g. a
  randomly selected Galileo signal dropped from 44 dB.Hz (no timing
  signal) to 37 dB.Hz (with timing signal summed), which should directly
  impact pseudo-range estimate (not verified, the recordings are only
  3-4 min. long).
• increasing the PRN power improves the SNR and hence the timing
  capability improves the synchronization to 0.2 ns, but only the
  strongest satellites of each constellation is decoded (two Galileo, no
  GPS L1)
• removing the GNSS antenna (replaced with 50 ohm load) returns to 5 ps
  standard deviation on 40 ms integration time, as expected.

My understanding: indeed summing the CDMA signals still allows
improving the SNR by N, the chip length, of the PRN code, but the SNR
defining the timing improvement has been degraded by adding the other
timing signal seen as noise by the orthogonal codes. The noise term on
the denominator is no longer thermal noise only but thermal + other
CDMA contributors. From the above discussion, the stronger the various
timing signals, the better their own correlation timing capability, but
the stronger the degradation of the other signal noise level.

Successive Interference Cancellation (SIC) might help remove the
deterministic term of this additional noise contribution, but in the
case of the GNSS signal added to the initially high SNR signal used for
timing, the deterministic GNSS contribution is 10 dB below the random
thermal noise, both amplified (in my case 43 dB, so reaching -64 dBm
in the useful 5 MHz bandwidth) to be well above the LSB of the ADC but
hence degrading the timing PRN capability. I cannot think of a way of
applying SIC to the random term of the GNSS antenna output.

The idea did sound attractive: maybe I missed a step in the
implementation or the processing.

Thanks, Jean-Michel

 
Yeah, the "coherently subtract a signal" is easy in theory, difficult in practice.  Considering something like a PN generator, you might have your "replica generator" synced up to a fraction of a chip, but there's often little problems with sample rate, etc. - and the noise in the input to the correlation that syncs your replica makes the "sync" uncertain - in particular with the amplitude.

I have been fooling with a scheme like this with some RTL-SDRs - put a pulsed tone (LeoBodnar GPSDO makes the 1pps pulse and the 10 MHz reference tone, which I convert to a variable amplitude pulse with a mixer)
Then look for the tone with correlation, model the frequency, phase, and amplitude, then subtract that from the raw samples.

Since I'm sampling at 2.048 MSa/s, and the pulse is 0.1 seconds long, and it's at a healthy SNR, I've got llots of samples to work with.  In fact, what I do is capture several seconds of data, run it through a FFT to make 2048 channels with a sample every millisecond, so I've got 100 samples (in a 1kHz BW) for each pulse.

It "sort of" works.  
The digital down converter in the RTL is set to 10.3 MHz, and I've  got a continuous test tone at 10.5 MHz. So in the sampled data, I have two signals. 

My "test" of the technique is that the phase of the test tone (after correcting with the frequency and time offset derived from the pulses) should match across 3 different receivers.
It does not - at least not very well.

Partly it's that the frequency of the RTL's oscillator drifts over 2 seconds (not much, but hey, fractions of a Hz make a difference). 

I've been distracted by other tasks recently, so I've not fooled with it in several months.  (Now I'm using USRPs, which, in theory, are synchronized with a common clock)

On Wed, 28 Jan 2026 19:32:32 +0100, jmfriedt via time-nuts time-nuts@lists.febo.com wrote:

I was so impressed with this idea that I had to test it (despite this
post being over 2 years old), and I am afraid it is not as easy as it
sounds.

I started from the setup described at
http://jmfriedt.free.fr/EFTF2025_jmfriedt.pdf
where two X310 SDRs are used to record the L1 and L5 GNSS bands with
one channel, and the other channel records a 5 MHz wide PRN sequence
generated from an FPGA, demonstrating ps synchronization of the SDR
channels (having previously demonstrated that the dual channel ADC
exhibit the same drift on both channels during warmup).

To try and free some channels, I summed the GNSS antenna output
(amplified 30 dB, converted to 70 MHz IF with 7 dB loss, and amplified
20 dB at baseband) with the FPGA PRN output. The result is rather
disappointing (at least wrt my expectations): attached is the plot of
the delay estimate between X310 channels from the PRN

• when adding the GNSS antenna output (blue chart), the time transfer
  capability is degrated from a few ps to 1 ns (standard deviation).
  Both American and European GNSS constellations are decoded with
  gnss-sdr. However the GNSS C/N0 has been degraded, for e.g. a
  randomly selected Galileo signal dropped from 44 dB.Hz (no timing
  signal) to 37 dB.Hz (with timing signal summed), which should directly
  impact pseudo-range estimate (not verified, the recordings are only
  3-4 min. long).
• increasing the PRN power improves the SNR and hence the timing
  capability improves the synchronization to 0.2 ns, but only the
  strongest satellites of each constellation is decoded (two Galileo, no
  GPS L1)
• removing the GNSS antenna (replaced with 50 ohm load) returns to 5 ps
  standard deviation on 40 ms integration time, as expected.

My understanding: indeed summing the CDMA signals still allows
improving the SNR by N, the chip length, of the PRN code, but the SNR
defining the timing improvement has been degraded by adding the other
timing signal seen as noise by the orthogonal codes. The noise term on
the denominator is no longer thermal noise only but thermal + other
CDMA contributors. From the above discussion, the stronger the various
timing signals, the better their own correlation timing capability, but
the stronger the degradation of the other signal noise level.

Successive Interference Cancellation (SIC) might help remove the
deterministic term of this additional noise contribution, but in the
case of the GNSS signal added to the initially high SNR signal used for
timing, the deterministic GNSS contribution is 10 dB below the random
thermal noise, both amplified (in my case 43 dB, so reaching -64 dBm
in the useful 5 MHz bandwidth) to be well above the LSB of the ADC but
hence degrading the timing PRN capability. I cannot think of a way of
applying SIC to the random term of the GNSS antenna output.

The idea did sound attractive: maybe I missed a step in the
implementation or the processing.

Thanks, Jean-Michel

time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com