WWVB BPSK Receiver Project?
On Thu, Mar 15, 2012 at 1:48 AM, Chuck Forsberg WA7KGX N2469R
caf@omen.com wrote:
How about this: Generate a precise 60 KHz signal from a GPSDO's 10 MHz.
Modulate it with 1 bit audio generated by a Linux program which would know
about DST.
The standard NTP source code distribution comes with a program to
generate the time code. So you'd not have the write it yourself.
It's purpose is to test the the WWV drivers n NTP. It is not built
by default, from memory the source is in a directory called "test".
But for those radio clocks in your house the new WWVB signal should
just work. They will not notice the phase modulation
Chris Albertson
Redondo Beach, California
In message 20120315152620.8347488e049854218aed4aa6@kinali.ch, Attila Kinali w
rites:
Do you need 16 bits or can you get by with a 12 bit ADC?
In general: The more the merrier, for a digital dude like me, having
more bits is easier than getting AGC working correctly :-)
Have you considered using an FPGA for signal processing? It seems
you need a fairly serious CPU to handle that much data.
I have considered FPGA, DSP would probably be more suitable, but
if I can do it in an ARM with C/Assy code, I prefer that.
I think Poul-Henning is refering to his AducLoran receiver,
That's one of the few experiements I bothered to document, I've been
doing similar stuff with DCF77 phase-code etc.
As long as you're after time/freq, you can use very deep averaging
which only takes a few instructions per sample, so for instance
the 42MHz Aduc7026 chip copes nicely with a single Loran-C signal.
I think I could squeeze a Loran-C navigation solution into it, if
I wanted to and as long as we're not talking too high speeds (again
allowing deep averaging) but I have not bothered.
A modern PC has a lot of computing power for stuff like this, and
is great for prototyping code, before dumping into a smaller chip.
That's how I found out that the circular-buffer averaging comb-filter
is a much better and stronger signal discriminator than almost anything
else you can come up with, for frequency/phase reception.
See for instance: http://phk.freebsd.dk/loran-c/CW/
--
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 Thu, Mar 15, 2012 at 3:13 PM, Poul-Henning Kamp phk@phk.freebsd.dk wrote:
In message 20120315152620.8347488e049854218aed4aa6@kinali.ch, Attila Kinali w
rites:
Do you need 16 bits or can you get by with a 12 bit ADC?
In general: The more the merrier, for a digital dude like me, having
more bits is easier than getting AGC working correctly :-)
Have you considered using an FPGA for signal processing? It seems
you need a fairly serious CPU to handle that much data.
"That much data" we are talking about 192K samples per second. I can
routinely record multiple tracks of 192K audio and do processing in
real time and the CPU meter hardly moves the bottom. Even a
gigabit per second Ethernet port is not "a lot of data" on a modern
computer.
FPGAs and DSP come into play if you are talking about tens of millions
of samples per second with data rates above say 200Mb/Sec But the
rate from an audio interface running 192K and 24-bits is still under
one megabyte per second. An interesting ratio is the number of CPU
cycles available to process one sample. On my Apple iMac that would
be about roughly 200,000 operations per data sample.
In real life SDR receivers even an older CPU can process the I and Q
channels and maintain a large graphic screen and send and receive data
over a network and still not be "maxed out"
Chris Albertson
Redondo Beach, California
PHK,
I'm interested in your circular averaging buffer: suppose 1K long, the 1st
sample goes into position 0, the 2nd into 1 ... the 1000th into 999 or, the
1st gets scaled and then summed with that already present in position 0
then the result back in position 0? And so on, of course, for position 1, 2
...
On Thu, Mar 15, 2012 at 11:48 PM, Chris Albertson <albertson.chris@gmail.com
wrote:
On Thu, Mar 15, 2012 at 3:13 PM, Poul-Henning Kamp phk@phk.freebsd.dk
wrote:
In message 20120315152620.8347488e049854218aed4aa6@kinali.ch, Attila
Kinali w
rites:
Do you need 16 bits or can you get by with a 12 bit ADC?
In general: The more the merrier, for a digital dude like me, having
more bits is easier than getting AGC working correctly :-)
Have you considered using an FPGA for signal processing? It seems
you need a fairly serious CPU to handle that much data.
"That much data" we are talking about 192K samples per second. I can
routinely record multiple tracks of 192K audio and do processing in
real time and the CPU meter hardly moves the bottom. Even a
gigabit per second Ethernet port is not "a lot of data" on a modern
computer.
FPGAs and DSP come into play if you are talking about tens of millions
of samples per second with data rates above say 200Mb/Sec But the
rate from an audio interface running 192K and 24-bits is still under
one megabyte per second. An interesting ratio is the number of CPU
cycles available to process one sample. On my Apple iMac that would
be about roughly 200,000 operations per data sample.
In real life SDR receivers even an older CPU can process the I and Q
channels and maintain a large graphic screen and send and receive data
over a network and still not be "maxed out"
Chris Albertson
Redondo Beach, California
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.
That would be big expensive filter. All you really need is the
average of the last N samples.
But with WWVB the bits are amplitude modulated at one bit per second.
so you want a big time constant on any AGC, maybe 100 seconds. If
you are sampling at 192K that would use way to much memory if you
stored each sample. Better to only keep running statistics. For
AGC you don't need to process every sample, you can feed the AGC a
subset of the sample stream. But with a 24b-t ADC you may not need
AGC
On Thu, Mar 15, 2012 at 4:01 PM, Azelio Boriani
azelio.boriani@screen.it wrote:
PHK,
I'm interested in your circular averaging buffer: suppose 1K long, the 1st
sample goes into position 0, the 2nd into 1 ... the 1000th into 999 or, the
1st gets scaled and then summed with that already present in position 0
then the result back in position 0? And so on, of course, for position 1, 2
...
On Thu, Mar 15, 2012 at 11:48 PM, Chris Albertson <albertson.chris@gmail.com
wrote:
On Thu, Mar 15, 2012 at 3:13 PM, Poul-Henning Kamp phk@phk.freebsd.dk
wrote:
In message 20120315152620.8347488e049854218aed4aa6@kinali.ch, Attila
Kinali w
rites:
Do you need 16 bits or can you get by with a 12 bit ADC?
In general: The more the merrier, for a digital dude like me, having
more bits is easier than getting AGC working correctly :-)
Have you considered using an FPGA for signal processing? It seems
you need a fairly serious CPU to handle that much data.
"That much data" we are talking about 192K samples per second. I can
routinely record multiple tracks of 192K audio and do processing in
real time and the CPU meter hardly moves the bottom. Even a
gigabit per second Ethernet port is not "a lot of data" on a modern
computer.
FPGAs and DSP come into play if you are talking about tens of millions
of samples per second with data rates above say 200Mb/Sec But the
rate from an audio interface running 192K and 24-bits is still under
one megabyte per second. An interesting ratio is the number of CPU
cycles available to process one sample. On my Apple iMac that would
be about roughly 200,000 operations per data sample.
In real life SDR receivers even an older CPU can process the I and Q
channels and maintain a large graphic screen and send and receive data
over a network and still not be "maxed out"
Chris Albertson
Redondo Beach, California
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.
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.
--
Chris Albertson
Redondo Beach, California
On 3/15/12 8:10 AM, J. Forster wrote:
Why make it simple when complicated also works?
-John
Can't get your doctorate doing something someone else has already
done...<grin>
Enormous literature out there on this, and it's been grist for many a
Master's or PhD dissertation.
All in a quest to get ever closer to the Shannon limit...
Frankly, my dear, I'd rather be a generalist.
-John
============
On 3/15/12 8:10 AM, J. Forster wrote:
Why make it simple when complicated also works?
-John
Can't get your doctorate doing something someone else has already
done...<grin>
Enormous literature out there on this, and it's been grist for many a
Master's or PhD dissertation.
All in a quest to get ever closer to the Shannon limit...
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.
In message CAL8XPmM+O0EP7yK7mUC16urmyBesWb+wR4UyJd5LrhLCSbWt=g@mail.gmail.com
, Azelio Boriani writes:
I'm interested in your circular averaging buffer: suppose 1K long, the 1st
sample goes into position 0, the 2nd into 1 ... the 1000th into 999 or, the
1st gets scaled and then summed with that already present in position 0
then the result back in position 0? And so on, of course, for position 1, 2
...
Yes.
And once you have filled a few seconds into the buffer, you can multiply
each of the 1000 locations with a nsine and ncosine, and sum the results
and you have a phase vector for the signal at n KHz.
For signals like DCF77 on half kHz grid, you need a 2 msec = 2000 samples
long buffer.
--
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 CABbxVHv0ZOmcwO6A1r8XRXjQ=v-rQw4dQorL9X8VA1qXA0rb4Q@mail.gmail.com
, Chris Albertson writes:
That would be big expensive filter. All you really need is the
average of the last N samples.
Expensive ? 2kB of memory ? Not even close to expensive.
But with a 24b-t ADC you may not need AGC
16 bits has meant that I never needed AGC.
--
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 14 Mar, 2012, at 18:08 , Brooke Clarke wrote:
The WWB paper "New Improved System for WWVB Broadcast" given at the 43rd PTTI November 2011 is at: http://jks.com/wwvb.pdf
Part of the processing gain comes directly from the BPSK modulation and that amounts to a little over 10 dB improvement, but there's a further 18 dB gain to be had by accumulating an hours worth of data and processing that.
It is a little interesting that the PTTI paper left out some
of the interesting details one would need to actually decode
the new signal, in particular the specification of the 14
second "Sync" sequence, which is necessary to know to find
the alignment of minutes, and the value of the "60-bit
hour-synchronization code", which defines the sequence
of phase reversals in each minute's modulation in an
hour and, as I understand it, is necessary to know to
take full advantage of the hour-averaging thing.
I assume this might have been done to allow the company
which participated in the design of the signal to complete
a receiver for it before they start transmitting that
way while keeping anyone else from starting a receiver
project until after the transmissions start?
Dennis Ferguson