[time-nuts] Re: Eloran long test from now to August or September.

[Jim Lux]

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 at lists.febo.com> wrote:

> 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.

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







>
> 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  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
>
>> On Sep 24, 2023, at 11:47 AM, paul swed via time-nuts wrote:
>>
>> 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 at lists.febo.com> wrote:
>>
>>> On 15/09/2023 14:43, john.haine--- via time-nuts wrote:
>>
>> This discussion reminds me, there is one eLoran station operating in the
>>> UK,
>>
>> co-located with the MSF transmitter at Anthorn, for research purposes.
>>> There is
>>
>> also some discussion about licensing some new operators mainly for
>>> timing
>>
>> purposes. Does anyone have any information on the coverage available
>>> from
>>
>> Anthorn please? John.
>>> 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 at blueyonder.co.uk
>>> Twitter: @gm8arv
>>> _______________________________________________
>>> time-nuts mailing list -- time-nuts at lists.febo.com
>>> To unsubscribe send an email to time-nuts-leave at lists.febo.com
>>
>> _______________________________________________
>> time-nuts mailing list -- time-nuts at lists.febo.com
>> To unsubscribe send an email to time-nuts-leave at lists.febo.com
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at lists.febo.com
> To unsubscribe send an email to time-nuts-leave at lists.febo.com
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at lists.febo.com
> To unsubscribe send an email to time-nuts-leave at lists.febo.com
_______________________________________________
time-nuts mailing list -- time-nuts at lists.febo.com
To unsubscribe send an email to time-nuts-leave at lists.febo.com
Â