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