Skip
The switch to settle is at least a clue that its got something by the tail.
A lot depends on the noise at your location. Its only increasing these days.
I need a drop of antenna work but dealing with LEE so maybe Sunday.
Looking forward to trying.
Regards
Paul

On Fri, Sep 15, 2023 at 9:56 AM Skip Withrow via time-nuts <
time-nuts@lists.febo.com> wrote:

John whats your approximate location?
I am near Boston and do not hear Anthorn when I try. When the chain was
operating years ago I could pick up a station at night, in the winter on
occasion. Thats maybe 2700 miles. Perhaps more. All skywave. Using a
preamplified whip antenna. Pretty much a loran c boat antenna.
But have heard nothing for quite a few years. I also for some reason
believe Anthorn is not running at full power. Something I read many years
ago.
The new eLORAN has several purposes. Timing, potentially navigation,
certainly emergency messaging. In the timing respect it can be very good
even in buildings with the coding used. (Its dangerous on Time-Nuts to say
very good. Humor)
Regards
Paul
WB8TSL

On Sat, Sep 16, 2023 at 12:40 AM john.haine--- via time-nuts <
time-nuts@lists.febo.com> wrote:

On 16/09/2023 17:26, john.haine--- via time-nuts wrote:

Airspy HF+ Discovery?

David

SatSignal Software - Quality software for you
Web: https://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk
Twitter: @gm8arv

I'm in the same area as John and I get a useble signal from MSF at 60kHz,
which is also at Anthorn. I don't know how the transmitters and antennae
compare, though.

On Sun, Sep 17, 2023 at 3:11 PM David Taylor via time-nuts <
time-nuts@lists.febo.com> wrote:

Adrian I can only speculate that they were as good as money allowed at the
time. They were both critical services so I doubt the government was cheap.
But that said the lower in frequency the system is the harder it is to get
something to radiate. In that respect eLORAN is just a bit more easy being
at 100 KHz. But still mighty hard. Not sure why its so hard to build a 70
KM vertical antenna and radials. Thats a total guess by the way.
Regards
Paul.

On Mon, Sep 18, 2023 at 12:21 AM Adrian Godwin via time-nuts <
time-nuts@lists.febo.com> wrote:

At 60 kHz the gap between ocean and the ionosphere is a waveguide,
which bends the signal to match the Earth's curvature, so
there is no theoretical limit to distance, as long as it is over
an ocean.

That is why the first commercial radio-telephone connection between
USA and UK in the 1920ies used 60 kHz.

At 100kHz there is no significant waveguide effect, quite the
contrary, you get "skywave" reflections, in particular at night.

Here is a recording of the "skywave dance" on a typical night at a
distance of approx 200km from the transmitter:

https://phk.freebsd.dk/AducLoran/animation2.gif

Loran-C uses the "3rd positive zero-crossing" as reference because
it is impossible for the skywave to arrive so early, given the height
of the ionosphere.

--
Poul-Henning Kamp      | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG        | TCP/IP since RFC 956
FreeBSD committer      | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

Well the 2100F seems to have started to grab something here in Boston
around 1300 local. Have a scope turned on and looking at the gated output
signal to see what might be there. Nothing all that obvious. If I get
anything it will be by skywave.
Regards
Paul

On Tue, Sep 19, 2023 at 11:18 AM Poul-Henning Kamp phk@phk.freebsd.dk
wrote:

On 15/09/2023 14:43, john.haine--- via time-nuts wrote:

Yes, I can confirm reception in Edinburgh using a Youloop antenna in an
attached garage.

So, is there any sort of software decoder for the signal?  I don't have a
specialised hardware receiver, just the usual SDR boxes including an Airspy HF+
Discovery.

Thanks,
David

SatSignal Software - Quality software for you
Web: https://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk
Twitter: @gm8arv

David
There have been various things posted in the past that have required A/Ds
and such. Poul here on Time-nuts did a semi software version. (I think) But
the fact is the old LORAN C receivers for frequency are a great way to go.
The only difference between LORAN C and eLORAN is the 9th pulse used as a
data channel. There was no 9th pulse in the old LORAN C. I have not seen
anything that describes the coding. It may be out there but I haven't been
interested in that. For many of us its an alternate very accurate Cesium
referenced source.
How it all develops if the governments supports it will be pretty
interesting. Certainly the old positioning is possible. The data channel
can provide propagation behaviors to allow for very accurate time and
positioning. The new generation receivers will all be SDR based.
I have actually seen an operational prototype numbers of years ago.
Regards
Paul
WB8TSL

On Sun, Sep 24, 2023 at 11:04 AM David Taylor via time-nuts <
time-nuts@lists.febo.com> wrote:

Hi

The issue with doing this with a low cost SDR board is not so much receiving / demodulating the
signal. It’s a pretty good bet somebody out there has been there / done that. The issue is pulling
an accurate “time pulse” out of your typical SDR setup.  This is a  somewhat unusual thing to want
to do. Finding a “stock” setup on a low cost board that does this will be a bit of a challenge.

Bob

One word - UrsaNav.

Kind regards,

John

https://linkedin.com/in/john-h-6a131b12/

I agree.  Most inexpensive SDRs, and more particularly, the gnuradio or other software, tends not to be designed for deterministic timing.  It is true that you can run some tests and empirically determine the delay through the software, but then, you have to worry about the non-deterministic behavior of the host OS. 

Typically, what you’d need is to simultaneously grab a counter running off the sample clock AND the ADC samples (presumably decimated in the hardware), and then you can deal with the uncertainty, and generate a count that can be compared against that same counter to generate an output pulse.  Most of the SDR hardware out there uses one of the multitude of chips that implements some form of pre filtering and decimation and post filtering - but those are typically deterministic in delay.  It’s everything after the interface to the host processor that’s non deterministic.  

Now, if you’re implementing the SDR on a dedicated processor, with no OS, and careful use of interrupts, you can do it.  But that’s what commercial timing receivers do. 

On Sun, 24 Sep 2023 12:38:34 -0400, Bob Camp via time-nuts time-nuts@lists.febo.com wrote:

Hi

The issue with doing this with a low cost SDR board is not so much receiving / demodulating the
signal. It’s a pretty good bet somebody out there has been there / done that. The issue is pulling
an accurate “time pulse” out of your typical SDR setup. This is a somewhat unusual thing to want
to do. Finding a “stock” setup on a low cost board that does this will be a bit of a challenge.

Bob

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

If I may disagree, the only part that matters when generating a timing information
from a SDR is the knowledge that not a single sample is lost in the periodic acquisition
by the ADC, and the time information encoded in the received message. Since both
information propagate through the asynchronous processing chain at the same rate, they
end up being decoded simultaneously and can be compared with each other to adjust e.g.
the clock of the ADC which also acts as the source of the 1-PPS generator. This is at
least what we did in http://jmfriedt.free.fr/ifcs2021.pdf: our initial error in this
investigation was indeed to try and steer the GP-CPU clock and use it to generate the
timing information, when the only deterministic part of the processing is in the FPGA
clocking the ADC.

Best, Jean-Michel

https://forum.pjrc.com/threads/45693-A-second-T31-Precision-Frequency-Standa
rd

On the second page of the thread he posts his Teensy code.

John.
-----Original Message-----
From: David Taylor via time-nuts time-nuts@lists.febo.com
Sent: Sunday, September 24, 2023 2:15 PM
To: time-nuts@lists.febo.com
Cc: David Taylor david-taylor@blueyonder.co.uk
Subject: [time-nuts] Re: Eloran long test from now to August or September.

On 15/09/2023 14:43, john.haine--- via time-nuts wrote:

Yes, I can confirm reception in Edinburgh using a Youloop antenna in an
attached garage.

So, is there any sort of software decoder for the signal?  I don't have a
specialised hardware receiver, just the usual SDR boxes including an Airspy
HF+ Discovery.

Thanks,
David

SatSignal Software - Quality software for you
Web: https://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk
Twitter: @gm8arv

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

Hej Bob,

On Sunday, 24 September 2023 18:38:34 CEST Bob Camp via time-nuts wrote:

Not that I have any experience in (E)Loran, but what about generating a time
signal yourself and adding it to the RF input (in the most basic realization
by simply pulsing off or AM modulating the RF input with an RF-switch, or
slightly more sophisticated by adding a micro-controller generated PRN-time-
code)? Then you you could recover the time-stamp from your recorded, de-
modulated data.

Cheers,
Jürgen

Hi

My point isn’t so much that it can’t be done. The point is that you are unlikely to find
a “stock” setup that does what you are after. You probably can’t just download this
project from that GitHub and you have it all going.

As mentioned in other posts, PHK did this all with a home brew SDR setup “way
back when”. It certainly can be done with enough effort put into the project.

What would you likely want to do? That’s obviously going to have a number of
answers depending on this or that.

Bob

John I don't see the code for the teensy?? It is quite a good description
of the LORAN signal and the new bit encoding.
I might see something like plumbing the teensy into a austron 2100. Simply
sniffing the RF out of the unit. Plenty of filtering and gain.
Regards
Paul

On Mon, Sep 25, 2023 at 10:27 AM john.haine--- via time-nuts <
time-nuts@lists.febo.com> wrote:

My bad it is on the second page of some 38.
Quite a good topic and detail and the code is there to attempt to decode
eurofix data one of two possible data transmissions.
Very nice work.
Regards
Paul

On Mon, Sep 25, 2023 at 10:49 AM paul swed paulswedb@gmail.com wrote:

The challenge is that most inexpensive SDR modules do not provide the time stamping of the ADC. They’re more a RF to stream of samples device.

Some of the devices could be programmed (in their FPGA logic) to do such a thing, but in the “out of the box” configuration, they don’t.  In your cited work you had to do this: “ the counter and control logic driving the 1-PPS generation have been added next to the existing dataflow handling logic as described at https://github.com/ oscimp/gnss-sdr-1pps.” 

As you discovered, this whole getting the phase of the 1pps “on the mark” is tricky - There’s all kinds of assumptions built into the default gnuradio (or other platform) that occasionally drop or add samples, so even if you have good time stamps, you spend a fair amount of time making sure that the time stamp remains aligned with the appropriate sample (particularly if there’s any resembling in the processing chain).

This is no reflection on your work, which is quite nice - it’s more that for a lot of SDR work, there wasn’t any thought to the need for precision timing - as long as you got RF in and the right bits out, the job is considered done.  This is especially so because the platform is inherently asynchronous (Ethernet and USB both have non-deterministic delays) and everyone uses some form of buffering to adapt to the uneven processing rates.

And this is especially so at the bottom of the price range - the RTL-SDR, the Red Pitaya, the Pluto.  - the “out of the box” configuration of software/FPGA is inappropriate for timing.

On Sun, 24 Sep 2023 19:59:12 +0000, "jeanmichel.friedt--- via time-nuts" time-nuts@lists.febo.com wrote:

If I may disagree, the only part that matters when generating a timing information
from a SDR is the knowledge that not a single sample is lost in the periodic acquisition
by the ADC, and the time information encoded in the received message. Since both
information propagate through the asynchronous processing chain at the same rate, they
end up being decoded simultaneously and can be compared with each other to adjust e.g.
the clock of the ADC which also acts as the source of the 1-PPS generator. This is at
least what we did in http://jmfriedt.free.fr/ifcs2021.pdf: our initial error in this
investigation was indeed to try and steer the GP-CPU clock and use it to generate the
timing information, when the only deterministic part of the processing is in the FPGA
clocking the ADC.

Best, Jean-Michel

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

See attached: I capacitively inject the 1-PPS on the RTL2832 input (either I or Q), not
the R820(T2) radiofrequency frontend. This allows for timestamping on the rising edge
of GPS 1-PPS the datastream fetched by the ADCs of the RTL-SDR.

Best, JM

Exactly.. That does work, although it requires opening up your RTL-SDR (and on V3, in HF receiver mode, the RF input is directly coupled to the Q input, without going through the front end downconverter.). It didn’t work well.
And ultimately, I was trying to figure out something that would work at Ku band, so I could “calibrate out” the delay through the LNB, the coax, and the RTL-SDR.  
The basic technique has been around since the 1960s.  Bracewell used it at Stanford, and a similar scheme was used for the Jansky VLA in New Mexico.

On Tue, 26 Sep 2023 19:24:21 +0000, jeanmichel.friedt@femto-st.fr wrote:

See attached: I capacitively inject the 1-PPS on the RTL2832 input (either I or Q), not
the R820(T2) radiofrequency frontend. This allows for timestamping on the rising edge
of GPS 1-PPS the datastream fetched by the ADCs of the RTL-SDR.

Best, JM

Agree very old and multi used idea.
For the clever ones in DSP, penetrate a time coherent spread spectrum that can be inband but under the noise floor of the collection bandwidth.  Correlate on receive in the same sample environment as you are doing science.

Lester B Veenstra  K1YCM  MØYCM  W8YCM  6Y6Y W8YCM/6Y 6Y8LV (Reformed USNSG CTM1)
lester@veenstras.com

452 Stable Ln
Keyser WV 26726 USA

GPS: 39.336826 N  78.982287 W (Google)
GPS: 39.33682 N  78.9823741 W (GPSDO)

Telephones:
Home:            +1-304-289-6057
US cell          +1-304-790-9192
Jamaica cell:    +1-876-456-8898

-----Original Message-----
From: Jim Lux via time-nuts [mailto:time-nuts@lists.febo.com]
Sent: Tuesday, September 26, 2023 3:33 PM
To: jeanmichel.friedt@femto-st.fr; time-nuts@lists.febo.com
Cc: Jim Lux
Subject: [time-nuts] Re: Eloran long test from now to August or September.

Exactly.. That does work, although it requires opening up your RTL-SDR (and on V3, in HF receiver mode, the RF input is directly coupled to the Q input, without going through the front end downconverter.). It didn’t work well.
And ultimately, I was trying to figure out something that would work at Ku band, so I could “calibrate out” the delay through the LNB, the coax, and the RTL-SDR.
The basic technique has been around since the 1960s.  Bracewell used it at Stanford, and a similar scheme was used for the Jansky VLA in New Mexico.

On Tue, 26 Sep 2023 19:24:21 +0000, jeanmichel.friedt@femto-st.fr wrote:

See attached: I capacitively inject the 1-PPS on the RTL2832 input (either I or Q), not
the R820(T2) radiofrequency frontend. This allows for timestamping on the rising edge
of GPS 1-PPS the datastream fetched by the ADCs of the RTL-SDR.

Best, JM

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

This is indeed the approach I promoted in
https://www.youtube.com/watch?v=rqa8VqSj7m8&t=9246s
but on a dedicated channel since the timing accuracy improvement over the sampling
period is determined by the signal to noise ratio during the peak fitting.
Thank you for the insight indeed.

--
JM Friedt, FEMTO-ST Time & Frequency, 26 rue de l'Epitaphe, 25000 Besancon, France

September 27, 2023 5:16 PM, "Lester Veenstra" m0ycm@veenstras.com wrote:

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