I guess the gr_clock_recovery_mm_cc.h was the only one - I know I got
3 or 4 other places on an earlier build, but I guess they've been
cleaned up in the current one. I haven't checked the packages I don't
use, though (gr-audio-portaudio, gr-comedi, gr-mc4020, gr-audio-oss,
or gr-audio-jack) I d
On Thursday 06 April 2006 15:11, Marcus Leech wrote:
> > Also, I think getting 32.768 MHz from 4Mhz with a PLL would be pretty
> > difficult (if not impossible)
>
> Given that you haven't looked into the PLLs on the FPGA, it's rather too
> early
> to conclude that you couldn't synthesize 32.768Mh
Farnell sell 32.768 MHz crystals (They're not what you'd call cheap though -
AU$17). Hmm they have 16.384 MHz ones for $12.81. Still not cheap..
Also, I think getting 32.768 MHz from 4Mhz with a PLL would be pretty
difficult (if not impossible)
Given that you haven't looked into the PLLs
On Thursday 06 April 2006 13:14, Martin Dvh wrote:
> Why don't you use the usrp to generate your 16.384 or 32.768 MHz refclock.
> Most daugterboards (except the tvrx) use this feature (They all use a 4Mhz
> refclock on io pin 0. The only difference with your design is that you need
> another freque
David Bengtson wrote:
> After far to long, I've updated the information on the Gnu Radio GPS
> board. I've finished a preliminary schematic, and I'd appreciate any
> comments that anyone might have.
Why don't you use the usrp to generate your 16.384 or 32.768 MHz refclock.
Most daugterboards (excep
Jens,
I would like to elaborate on some of your comments.
I am using the following notation:
N fft size (2048)
G guard interval (504)
v0 fractional frequency offset
f0=v0 T absolute frequency offset
tau0 fractional time offset
t0=tau0 T absolute timne offset
To sum up:
Frequency offset result
Is there an inherent problem with using the DBS Rx? I think this
discussion started once, but I can't find it in the archives.
Has any one successfully captured GPS and processed out position
information using GNU Radio and USRP? I remember Krys Kamieniecki was
working on it, but last I remem
After far to long, I've updated the information on the Gnu Radio GPS
board. I've finished a preliminary schematic, and I'd appreciate any
comments that anyone might have.
Page:
http://www.keystoneradio.com/grGPS.html
Schematic
http://www.keystoneradio.com/pdfs/Schematic_1.pdf
Thanks
Dave
John -
I must have been drunk when I wrote those equations. I wrote 64e10 when
I meant 64e6, and put the D in a weird place. Sorry for any confusion.
This makes more sense:
(16 bit/sample)*(64e6/D sample/sec)*(1/2^23 MB/bit) <= 32 MB/sec
therefore, for real
D >= 16*64e6/(32*2^23) = 3.81 --> D
The FM stereo simple block, wfm_rcv_pll.py, has been modified to
recover the carrier using gr_pll_carriertracking. I noticed an
immediate drop in the hiss here. We probably need to do some gain
management but that can wait until I have the remainder of the
modifications in line and the stere
On Wed, Apr 05, 2006 at 02:30:30PM -0700, jjw wrote:
>
> I know this is probably an extremely stupid question, but I wanted to get
> some verification. I've noticed that the minimum decimation rate you can
> use in all of the sample programs is 4 (giving you an effective sampling
> rate of 16 MHz
On Wed, Apr 05, 2006 at 05:27:51PM -0400, Charles Swiger wrote:
> On Wed, 2006-04-05 at 10:16 -0700, Eric Blossom wrote:
>
> > I moved it all to a new module, gr-atsc in CVS.
> >
> > It's already autoconfiscated and ready to go. There's a file,
> > README.signal_flow in the top level directory t
Hi John -
16/D bits/sample x 64e10 samples/sec x 1 B/8 bits x 1 MB / 2^20 B <= 32
MB/sec
Therefore,
D >= 16*64e10 /(32*8*2^20) = 3.814 -> 4
So, if you want to transmit twice as many sample across the bus...
D > = 2*16*64e10 /(32*8*2^20) = 7.63 -> 8
...you have to halve your sampling frequency
I know this is probably an extremely stupid question, but I wanted to get
some verification. I've noticed that the minimum decimation rate you can
use in all of the sample programs is 4 (giving you an effective sampling
rate of 16 MHz). If you are transmitting 1 real channel of data (16 bits)
at
On Wed, 2006-04-05 at 10:16 -0700, Eric Blossom wrote:
> I moved it all to a new module, gr-atsc in CVS.
>
> It's already autoconfiscated and ready to go. There's a file,
> README.signal_flow in the top level directory that tells how the old
> code was connected together. There are loopback tes
It will not be possible to recover the signal if the real signal is at
zero IF (and predetection) so we will assume that it is not at zero.
The simplest possible FM detector is a zero crossing counter. That is,
you output a signal that is proportional to the distance between zero
crossings.
Can you say a dozen times:
"Bob is not a C++ programmer"
"Bob is not a C++ programmer"
. . . . .
Ooopsy. Basically every function I have written or had a hand in. MEA
CULPA.
Bob
Eric Blossom wrote:
On Wed, Apr 05, 2006 at 12:54:37PM -0700, Erik Tollerud wrote:
I'm building on FC4 w
On Wed, Apr 05, 2006 at 01:17:06PM -0700, Eric Blossom wrote:
> On Wed, Apr 05, 2006 at 12:54:37PM -0700, Erik Tollerud wrote:
> > I'm building on FC4 with GCC 4.1.0, and I get a bunch of "extra
> > qualification" errors in the C++ code where static functions are
> > declared inside a class with th
On Wed, Apr 05, 2006 at 12:54:37PM -0700, Erik Tollerud wrote:
> I'm building on FC4 with GCC 4.1.0, and I get a bunch of "extra
> qualification" errors in the C++ code where static functions are
> declared inside a class with the class name prefixed... for example,
> from gnuradio-core/src/lib/gen
I'm building on FC4 with GCC 4.1.0, and I get a bunch of "extra
qualification" errors in the C++ code where static functions are
declared inside a class with the class name prefixed... for example,
from gnuradio-core/src/lib/general/gr_clock_recovery_mm_cc.h, there's
a class that looks like:
class
Yes. Here is what you are missing:
Let us concentrate (as does your nice animated gif) on one channel in
the OFDM.
Let us suppose you have a variable delay into the signal after its
onset. This will happen with probability one because your clock and the
transmitter clock will not be the sam
On Wed, Apr 05, 2006 at 06:12:06PM +0200, Luis Simoes wrote:
> Hi all,
>
> I tried to use benchmark_gmsk_rx.py and i noticed that my system does not
> have
> all the usrp stuff receive_path.py uses. So I install the usrp-011 and the
> gr-usrp-0.7 package and uninstall the previous ones (usrp-0.
On Wed, Apr 05, 2006 at 03:44:59PM +0200, Matteo Campanella wrote:
> Hello, I am quite stuck at a problem, that is, how to demodulate a FM
> signal that is NOT in complex form using existing gnuradio blocks. The
> quadrature demodulator works only with complex input; I have tried to
> build an anal
On Wed, Apr 05, 2006 at 06:10:11AM -0700, seph 004 wrote:
> Hi
>
> I'm trying to reinstall the gnuradio files from cvs. I get all the files and
> start the ./bootstrap then ./configure procedure. When it comes to executing
> 'make' however, it keeps breaking down with the following error:
>
Can USRP implement GPS trigger from GPS one second pulse?
I want to synchronize USRP with my transmitter by the falling edge of
GPS one second pulse.
Does anybody know how to do this?
Thanks in advance.
Jing
___
Discuss-gnuradio mailing list
Discuss-gn
> Thank you very much for the reference. This was a very nice link to
> Mostofi's work. The following paper is also pertinent to Jen's thinking
> on the guard interval offset being irrelevant. It is not of course:
>
> *Y. Mostofi*, D. Cox and A. Bahai, "Effect of Timing Synchronization
> Er
Hi all,
I tried to use benchmark_gmsk_rx.py and i noticed that my system does not have
all the usrp stuff receive_path.py uses. So I install the usrp-011 and the
gr-usrp-0.7 package and uninstall the previous ones (usrp-0.8 and
gr-usrp-0.5). After finishing (I am still running on gnuradio-cor 2
Thanks for the reply! I'm really struggeling here...
> Yes, I think this is a critical step. small letters are time domain and
> capital letters are frequency domain.
>
> x(n) ---> X(k)
> FFT
>
> x(n-n') -> e^(j*2*pi*n'*k/N) * X(k)
> FFT
>
> for one OFDM sy
I have tried building the analytic by hilbert, but I think that, because
of the many near DC components of the signal, I do not get a nice
quadrature demod output...I will try with a pll, thanks for the
suggestion!
MC
> Matteo Campanella wrote:
>> Hello, I am quite stuck at a problem, that is, ho
Achilleas,
my estimate is based on frequency domain correlation. Just count the
offset of the maximum (o). Then estimate the fractional offset (fo) by taking
the
value left (l) and right (r) of the maximum and calculate fo = (r-l)/(r+l).
To compensate substract the resulting frequency offset (o+f
Matteo Campanella wrote:
> Hello, I am quite stuck at a problem, that is, how to demodulate a FM
> signal that is NOT in complex form using existing gnuradio blocks. The
> quadrature demodulator works only with complex input; I have tried to
> build an analytic signal out of my real one, but the re
Hello, I am quite stuck at a problem, that is, how to demodulate a FM
signal that is NOT in complex form using existing gnuradio blocks. The
quadrature demodulator works only with complex input; I have tried to
build an analytic signal out of my real one, but the result of the
demodulation is then
seph 004 wrote:
Hi
I'm trying to reinstall the gnuradio files from cvs. I get all the files
and start the ./bootstrap then ./configure procedure. When it comes to
executing 'make' however, it keeps breaking down with the following error:
make[4]: Entering directory
`/home/lance/gr-build/gnu
Hi I'm trying to reinstall the gnuradio files from cvs. I get all the files and start the ./bootstrap then ./configure procedure. When it comes to executing 'make' however, it keeps breaking down with the following error: make[4]: Entering directory `/home/lance/gr-build/gnuradio-core/src/lib/swi
34 matches
Mail list logo
