time-nuts@lists.febo.com

Discussion of precise time and frequency measurement

View all threads

Re: [time-nuts] WWVB BPSK Receiver Project? (fwd)

TV
Tom Van Baak
Fri, Mar 16, 2012 4:59 PM

Bob,

To address that diurnal phase issue, for fun, we could set up a
cloud-based time-nuts WWVB common view network. With a
couple of sites in each state, imagine the wonderful daily or
hourly animated plots that would result.

/tvb

Hi

My main concern on short averages is the relatively long path from WWVB to
most of the target audience. The day / night phase shift is fairly
significant over a long path. That's something I would want to process out.
Since it (hopefully) is predictable, it's just another thing to feed into
the signal estimation side of the process.

Bob

Bob, To address that diurnal phase issue, for fun, we could set up a cloud-based time-nuts WWVB common view network. With a couple of sites in each state, imagine the wonderful daily or hourly animated plots that would result. /tvb > Hi > > My main concern on short averages is the relatively long path from WWVB to > most of the target audience. The day / night phase shift is fairly > significant over a long path. That's something I would want to process out. > Since it (hopefully) is predictable, it's just another thing to feed into > the signal estimation side of the process. > > Bob
BC
Bob Camp
Fri, Mar 16, 2012 7:26 PM

Hi

With a reasonable sized data set, I suspect we would learn some things about
the phase shift process. The better we can model the process, the better we
can anticipate it and correct for it in the code.

Bob

-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@febo.com] On
Behalf Of Tom Van Baak
Sent: Friday, March 16, 2012 12:59 PM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] WWVB BPSK Receiver Project? (fwd)

Bob,

To address that diurnal phase issue, for fun, we could set up a
cloud-based time-nuts WWVB common view network. With a
couple of sites in each state, imagine the wonderful daily or
hourly animated plots that would result.

/tvb

Hi

My main concern on short averages is the relatively long path from WWVB to
most of the target audience. The day / night phase shift is fairly
significant over a long path. That's something I would want to process

out.

Since it (hopefully) is predictable, it's just another thing to feed into
the signal estimation side of the process.

Bob


time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Hi With a reasonable sized data set, I suspect we would learn some things about the phase shift process. The better we can model the process, the better we can anticipate it and correct for it in the code. Bob -----Original Message----- From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@febo.com] On Behalf Of Tom Van Baak Sent: Friday, March 16, 2012 12:59 PM To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] WWVB BPSK Receiver Project? (fwd) Bob, To address that diurnal phase issue, for fun, we could set up a cloud-based time-nuts WWVB common view network. With a couple of sites in each state, imagine the wonderful daily or hourly animated plots that would result. /tvb > Hi > > My main concern on short averages is the relatively long path from WWVB to > most of the target audience. The day / night phase shift is fairly > significant over a long path. That's something I would want to process out. > Since it (hopefully) is predictable, it's just another thing to feed into > the signal estimation side of the process. > > Bob _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
MP
Marek Peca
Sat, Mar 17, 2012 12:08 AM

Hello,

thank you for your oppinion.

On Thu, 15 Mar 2012, Poul-Henning Kamp wrote:

In message Pine.LNX.4.64.1203152001370.3542@tesla, Marek Peca writes:

Yes, it should work on any USB audio capable OS, ie. Linux, Windows,
MacOS etc.

I would like to recommend against this approach for a number of reasons.

First, yes, while you can do undersampling and such, it puts very high
requirements on your analog filters.

The reason I use 1MSPS is that it allows me to use a very sloppy
low-pass filter filter which just cuts off somewhere around 150-200 kHz,
and do everything else in software.

This means that I have no phase/group-delay distortion in the analog
part that I need to compensate in software.

It also means that I don't have to change hardware to play with different
signals, they're all there, all the time, for instance the stuff under
http://phk.freebsd.dk/Leap/
is pulled out that way.
(..)

You are right. I admit, that using comfortable oversampling, the converter
is more versatile and analogue-side filters are absolutely non-critical
ones. Nothing against that, moreover, I confess that I often use this
approach, oversampling & simple anti-aliasing, rather than converse.

Now, I am still unsure whether to deploy the relatively cheap lower
performance board with sampling in order of 40..80ksps.

You are right, that 1Msps solves the task better or at least with the same
performance. But, you pay few $ more (not so important), some few watts
more and take more data before decimation (may be done in FPGA, of
course). I know that USB2.0 handles >30MB/s on majority of HW&OSes and you
still need only about 2MB/s.

My only argument against your versatile and well-performing solution is
that it is a little bit overkill. In other words, it would be certainly
better to buy USRP N210, then you may sample directly 0..250MHz @>100Msps,
and 1Gbps Ethernet is quite common these days, too. You have everything
coded inside and its software support is also very good, including virtual
soundcard connection etc.

My point is to do something with relevant performance wrt. <10kHz wide
LF signals.

Well, I still think that 40..100ksps (1-2 inputs) module acting like a
SAR sound-card may be usable as well as 1Msps for LF time-nuttery with a
bare ferrite rod, and together with a mixer for DRM and Synchronous AM
fans.

The useful bandwidth of LF to HF radio is about 9kHz, DCF77-like standards
with PRBS is about 1.5kHz. Of course the ferrite rod as an input filter
will have a non-linear phase, but it still seems to me it is the
simplest and most common receiptor for LF time signals.

Well, I will wait for more reactions, till now I have 2 positive and
1 yours, discouraging from 40ksps approach.

Thank you and please note my respect to your approach and achievements.

Best regards,
Marek

Hello, thank you for your oppinion. On Thu, 15 Mar 2012, Poul-Henning Kamp wrote: > > In message <Pine.LNX.4.64.1203152001370.3542@tesla>, Marek Peca writes: > >> Yes, it should work on any USB audio capable OS, ie. Linux, Windows, >> MacOS etc. > > I would like to recommend against this approach for a number of reasons. > > First, yes, while you can do undersampling and such, it puts very high > requirements on your analog filters. > > The reason I use 1MSPS is that it allows me to use a very sloppy > low-pass filter filter which just cuts off somewhere around 150-200 kHz, > and do everything else in software. > > This means that I have no phase/group-delay distortion in the analog > part that I need to compensate in software. > > It also means that I don't have to change hardware to play with different > signals, they're all there, all the time, for instance the stuff under > http://phk.freebsd.dk/Leap/ > is pulled out that way. > (..) You are right. I admit, that using comfortable oversampling, the converter is more versatile and analogue-side filters are absolutely non-critical ones. Nothing against that, moreover, I confess that I often use this approach, oversampling & simple anti-aliasing, rather than converse. Now, I am still unsure whether to deploy the relatively cheap lower performance board with sampling in order of 40..80ksps. You are right, that 1Msps solves the task better or at least with the same performance. But, you pay few $ more (not so important), some few watts more and take more data before decimation (may be done in FPGA, of course). I know that USB2.0 handles >30MB/s on majority of HW&OSes and you still need only about 2MB/s. My only argument against your versatile and well-performing solution is that it is a little bit overkill. In other words, it would be certainly better to buy USRP N210, then you may sample directly 0..250MHz @>100Msps, and 1Gbps Ethernet is quite common these days, too. You have everything coded inside and its software support is also very good, including virtual soundcard connection etc. My point is to do something with relevant performance wrt. <10kHz wide LF signals. Well, I still think that 40..100ksps (1-2 inputs) module acting like a SAR sound-card may be usable as well as 1Msps for LF time-nuttery with a bare ferrite rod, and together with a mixer for DRM and Synchronous AM fans. The useful bandwidth of LF to HF radio is about 9kHz, DCF77-like standards with PRBS is about 1.5kHz. Of course the ferrite rod as an input filter *will* have a non-linear phase, but it still seems to me it is the simplest and most common receiptor for LF time signals. Well, I will wait for more reactions, till now I have 2 positive and 1 yours, discouraging from 40ksps approach. Thank you and please note my respect to your approach and achievements. Best regards, Marek
G
gary
Sat, Mar 17, 2012 3:02 AM

I lost track of who wrote this, but why is it assume a ferrite rod has
non-linear phase. [Group delay error I presume). Now I assume this
presumes the rod is used in a LC circuit, but if the Q is not high, the
phase linearity won't necessarily be bad.

Basically I'd like to hear more from whomever wrote this.

"The useful bandwidth of LF to HF radio is about 9kHz, DCF77-like
standards with PRBS is about 1.5kHz. Of course the ferrite rod as an
input filter will have a non-linear phase, but it still seems to me it
is the simplest and most common receiptor for LF time signals."

I lost track of who wrote this, but why is it assume a ferrite rod has non-linear phase. [Group delay error I presume). Now I assume this presumes the rod is used in a LC circuit, but if the Q is not high, the phase linearity won't necessarily be bad. Basically I'd like to hear more from whomever wrote this. "The useful bandwidth of LF to HF radio is about 9kHz, DCF77-like standards with PRBS is about 1.5kHz. Of course the ferrite rod as an input filter *will* have a non-linear phase, but it still seems to me it is the simplest and most common receiptor for LF time signals."
PK
Poul-Henning Kamp
Sat, Mar 17, 2012 7:20 AM

In message Pine.LNX.4.64.1203170042050.2576@tesla, Marek Peca writes:

My only argument against your versatile and well-performing solution is
that it is a little bit overkill.

As if running a handfull precision oscillators just for fun isn't
"overkill" also ? :-)

In other words, it would be certainly better to buy USRP N210,

Actually that would be a very idea, because you cannot get rid of
the down-sampler in the USRP and that would make Loran-C reception
very tricky to implement.

My point is to do something with relevant performance wrt. <10kHz wide
LF signals.

The crucial question is if your are doing timenuttery or radionuttery.

If you are doing timenuttery, you want you ADC synchronized to your
OCXO/Rb/Cs or whatever you have, and you don't want to have to deal
with getting your IF frequency locked too.

Soundcards use inconvenient frequencies and are seldom built to take
an external clock signal.

The useful bandwidth of LF to HF radio is about 9kHz,

You need more than 25kHz for good Loran-C

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

In message <Pine.LNX.4.64.1203170042050.2576@tesla>, Marek Peca writes: >My only argument against your versatile and well-performing solution is >that it is a little bit overkill. As if running a handfull precision oscillators just for fun isn't "overkill" also ? :-) >In other words, it would be certainly better to buy USRP N210, Actually that would be a very idea, because you cannot get rid of the down-sampler in the USRP and that would make Loran-C reception very tricky to implement. >My point is to do something with relevant performance wrt. <10kHz wide >LF signals. The crucial question is if your are doing timenuttery or radionuttery. If you are doing timenuttery, you want you ADC synchronized to your OCXO/Rb/Cs or whatever you have, and you don't want to have to deal with getting your IF frequency locked too. Soundcards use inconvenient frequencies and are seldom built to take an external clock signal. >The useful bandwidth of LF to HF radio is about 9kHz, You need more than 25kHz for good Loran-C -- 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.
AK
Attila Kinali
Sat, Mar 17, 2012 9:47 AM

On Fri, 16 Mar 2012 20:02:27 -0700
gary lists@lazygranch.com wrote:

I lost track of who wrote this, but why is it assume a ferrite rod has
non-linear phase. [Group delay error I presume). Now I assume this
presumes the rod is used in a LC circuit, but if the Q is not high, the
phase linearity won't necessarily be bad.

Basically I'd like to hear more from whomever wrote this.

"The useful bandwidth of LF to HF radio is about 9kHz, DCF77-like
standards with PRBS is about 1.5kHz. Of course the ferrite rod as an
input filter will have a non-linear phase, but it still seems to me it
is the simplest and most common receiptor for LF time signals."

I'm not the one who wrote this, but it is true :-)
Any filter has its phase dependend on the frequency. As a rule
of thumb: the higher order the filter, the faster the phase changes.

As long as you just do straight filtering, with no feed back, you
care seldom about the phase. It's the amplitude of the signal you
are interested in. But if you now go time nuttery, phase change means
delay. And you dont know how large it exactly is, because you dont
know where exactly the resonance frequency of the filter is. And more
importantly, you cannot say how it changes over time (tempeture dependece,
aging, etc).

That said, i think this can be ignored for all practical purposes
in an VLF receiver, as the enviromental changes in the atmospheric
signal path are much larger than the small error you get from the
filter. But then again, time nuts are time nuts ;)

		Attila Kinali

--
Why does it take years to find the answers to
the questions one should have asked long ago?

On Fri, 16 Mar 2012 20:02:27 -0700 gary <lists@lazygranch.com> wrote: > I lost track of who wrote this, but why is it assume a ferrite rod has > non-linear phase. [Group delay error I presume). Now I assume this > presumes the rod is used in a LC circuit, but if the Q is not high, the > phase linearity won't necessarily be bad. > > Basically I'd like to hear more from whomever wrote this. > > > "The useful bandwidth of LF to HF radio is about 9kHz, DCF77-like > standards with PRBS is about 1.5kHz. Of course the ferrite rod as an > input filter *will* have a non-linear phase, but it still seems to me it > is the simplest and most common receiptor for LF time signals." I'm not the one who wrote this, but it is true :-) Any filter has its phase dependend on the frequency. As a rule of thumb: the higher order the filter, the faster the phase changes. As long as you just do straight filtering, with no feed back, you care seldom about the phase. It's the amplitude of the signal you are interested in. But if you now go time nuttery, phase change means delay. And you dont know how large it exactly is, because you dont know where exactly the resonance frequency of the filter is. And more importantly, you cannot say how it changes over time (tempeture dependece, aging, etc). That said, i think this can be ignored for all practical purposes in an VLF receiver, as the enviromental changes in the atmospheric signal path are much larger than the small error you get from the filter. But then again, time nuts are time nuts ;) Attila Kinali -- Why does it take years to find the answers to the questions one should have asked long ago?
PK
Poul-Henning Kamp
Sat, Mar 17, 2012 10:01 AM

In message 20120317104723.8c1832454f14a3f91a4fb4c0@kinali.ch, Attila Kinali w
rites:

That said, i think this can be ignored for all practical purposes
in an VLF receiver, as the enviromental changes in the atmospheric
signal path are much larger than the small error you get from the
filter. But then again, time nuts are time nuts ;)

Again: it most certainly can not be ignored for Loran-C

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

In message <20120317104723.8c1832454f14a3f91a4fb4c0@kinali.ch>, Attila Kinali w rites: >That said, i think this can be ignored for all practical purposes >in an VLF receiver, as the enviromental changes in the atmospheric >signal path are much larger than the small error you get from the >filter. But then again, time nuts are time nuts ;) Again: it most certainly can not be ignored for Loran-C -- 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.
AK
Attila Kinali
Sat, Mar 17, 2012 10:11 AM

On Sat, 17 Mar 2012 10:01:13 +0000
"Poul-Henning Kamp" phk@phk.freebsd.dk wrote:

That said, i think this can be ignored for all practical purposes
in an VLF receiver, as the enviromental changes in the atmospheric
signal path are much larger than the small error you get from the
filter. But then again, time nuts are time nuts ;)

Again: it most certainly can not be ignored for Loran-C

Could you explain why? Yes, you need a higher BW for Loran-C,
but the phase(f) function will give you only a distortion of
the signal and a constant time delay in your signal recovery.
But that shouldnt degrade the usefullness of the system.
What am i missing here?

		Attila Kinali

--
Why does it take years to find the answers to
the questions one should have asked long ago?

On Sat, 17 Mar 2012 10:01:13 +0000 "Poul-Henning Kamp" <phk@phk.freebsd.dk> wrote: > >That said, i think this can be ignored for all practical purposes > >in an VLF receiver, as the enviromental changes in the atmospheric > >signal path are much larger than the small error you get from the > >filter. But then again, time nuts are time nuts ;) > > Again: it most certainly can not be ignored for Loran-C Could you explain why? Yes, you need a higher BW for Loran-C, but the phase(f) function will give you only a distortion of the signal and a constant time delay in your signal recovery. But that shouldnt degrade the usefullness of the system. What am i missing here? Attila Kinali -- Why does it take years to find the answers to the questions one should have asked long ago?
PK
Poul-Henning Kamp
Sat, Mar 17, 2012 10:15 AM

In message 20120317111119.9536107ebf82050fe14ee85c@kinali.ch, Attila Kinali w
rites:

On Sat, 17 Mar 2012 10:01:13 +0000

Could you explain why? Yes, you need a higher BW for Loran-C,
but the phase(f) function will give you only a distortion of
the signal and a constant time delay in your signal recovery.
But that shouldnt degrade the usefullness of the system.
What am i missing here?

Either you need to characterize the exact behaviour of your filter
and build the necessary compensation for its phase/frequency behaviour
into your receiver, or you need a very flat filter (both freq+phase)
in order to reliably recognize the proper zero-crossing to track.

The more you disturb a Loran-C pulse, the more it just looks like
a bit of a sine-function, and the harder it is to lock on the right
zero-crossing.

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

In message <20120317111119.9536107ebf82050fe14ee85c@kinali.ch>, Attila Kinali w rites: >On Sat, 17 Mar 2012 10:01:13 +0000 >Could you explain why? Yes, you need a higher BW for Loran-C, >but the phase(f) function will give you only a distortion of >the signal and a constant time delay in your signal recovery. >But that shouldnt degrade the usefullness of the system. >What am i missing here? Either you need to characterize the exact behaviour of your filter and build the necessary compensation for its phase/frequency behaviour into your receiver, or you need a very flat filter (both freq+phase) in order to reliably recognize the proper zero-crossing to track. The more you disturb a Loran-C pulse, the more it just looks like a bit of a sine-function, and the harder it is to lock on the right zero-crossing. -- 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.
L
lists@lazygranch.com
Sat, Mar 17, 2012 10:27 AM

I've designed filters for datacom chips. I know filtering. My point is the original author is making some assumptions in the design which are not stated.

What I don't have a lot of hands on experience is with open circuit magnetics. (I do with closed circuit magnetics.) But I claim if the ferrite rod antenna is not capacitively loaded to resonate at the comm frequency, then there isn't significant group delay error.

The antenna will have a natural resonant frequency comprised of the inductance and parasitic capacitance. But this represents an upper frequency limit. So simply operate below resonance and the group delay error is minimized. Filtering can be done following the preamp that connects to the antenna, and thus will not interact with it.

-----Original Message-----
From: Attila Kinali attila@kinali.ch
Sender: time-nuts-bounces@febo.com
Date: Sat, 17 Mar 2012 10:47:23
To: Discussion of precise time and frequency measurementtime-nuts@febo.com
Reply-To: Discussion of precise time and frequency measurement
time-nuts@febo.com
Subject: Re: [time-nuts] WWVB BPSK Receiver Project? (fwd)

On Fri, 16 Mar 2012 20:02:27 -0700
gary lists@lazygranch.com wrote:

I lost track of who wrote this, but why is it assume a ferrite rod has
non-linear phase. [Group delay error I presume). Now I assume this
presumes the rod is used in a LC circuit, but if the Q is not high, the
phase linearity won't necessarily be bad.

Basically I'd like to hear more from whomever wrote this.

"The useful bandwidth of LF to HF radio is about 9kHz, DCF77-like
standards with PRBS is about 1.5kHz. Of course the ferrite rod as an
input filter will have a non-linear phase, but it still seems to me it
is the simplest and most common receiptor for LF time signals."

I'm not the one who wrote this, but it is true :-)
Any filter has its phase dependend on the frequency. As a rule
of thumb: the higher order the filter, the faster the phase changes.

As long as you just do straight filtering, with no feed back, you
care seldom about the phase. It's the amplitude of the signal you
are interested in. But if you now go time nuttery, phase change means
delay. And you dont know how large it exactly is, because you dont
know where exactly the resonance frequency of the filter is. And more
importantly, you cannot say how it changes over time (tempeture dependece,
aging, etc).

That said, i think this can be ignored for all practical purposes
in an VLF receiver, as the enviromental changes in the atmospheric
signal path are much larger than the small error you get from the
filter. But then again, time nuts are time nuts ;)

		Attila Kinali

--
Why does it take years to find the answers to
the questions one should have asked long ago?


time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

I've designed filters for datacom chips. I know filtering. My point is the original author is making some assumptions in the design which are not stated. What I don't have a lot of hands on experience is with open circuit magnetics. (I do with closed circuit magnetics.) But I claim if the ferrite rod antenna is not capacitively loaded to resonate at the comm frequency, then there isn't significant group delay error. The antenna will have a natural resonant frequency comprised of the inductance and parasitic capacitance. But this represents an upper frequency limit. So simply operate below resonance and the group delay error is minimized. Filtering can be done following the preamp that connects to the antenna, and thus will not interact with it. -----Original Message----- From: Attila Kinali <attila@kinali.ch> Sender: time-nuts-bounces@febo.com Date: Sat, 17 Mar 2012 10:47:23 To: Discussion of precise time and frequency measurement<time-nuts@febo.com> Reply-To: Discussion of precise time and frequency measurement <time-nuts@febo.com> Subject: Re: [time-nuts] WWVB BPSK Receiver Project? (fwd) On Fri, 16 Mar 2012 20:02:27 -0700 gary <lists@lazygranch.com> wrote: > I lost track of who wrote this, but why is it assume a ferrite rod has > non-linear phase. [Group delay error I presume). Now I assume this > presumes the rod is used in a LC circuit, but if the Q is not high, the > phase linearity won't necessarily be bad. > > Basically I'd like to hear more from whomever wrote this. > > > "The useful bandwidth of LF to HF radio is about 9kHz, DCF77-like > standards with PRBS is about 1.5kHz. Of course the ferrite rod as an > input filter *will* have a non-linear phase, but it still seems to me it > is the simplest and most common receiptor for LF time signals." I'm not the one who wrote this, but it is true :-) Any filter has its phase dependend on the frequency. As a rule of thumb: the higher order the filter, the faster the phase changes. As long as you just do straight filtering, with no feed back, you care seldom about the phase. It's the amplitude of the signal you are interested in. But if you now go time nuttery, phase change means delay. And you dont know how large it exactly is, because you dont know where exactly the resonance frequency of the filter is. And more importantly, you cannot say how it changes over time (tempeture dependece, aging, etc). That said, i think this can be ignored for all practical purposes in an VLF receiver, as the enviromental changes in the atmospheric signal path are much larger than the small error you get from the filter. But then again, time nuts are time nuts ;) Attila Kinali -- Why does it take years to find the answers to the questions one should have asked long ago? _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.