Hi,
I have a rev 3 USRP and I will be using an external clock. Instructions
at http://gnuradio.utah.edu/trac/wiki/USRPClockingNotes report, among
other things "cut the traces coming from X2".
Q1: Which of the X2 traces are coming from X2?
Q2: If I should cut all the X2 traces, why not just
Wireless Monster wrote:
Hi Brian,
Thank you for your help. Looks good :)
So If I understood correctly I can do the following:
I set the USRP interpolator to 64, so the USRP sink will consume samples
at a 2MS/s. I add the resampler just before with a ratio 16/13 so I it
consumes samples with a
Brian, Dan,
Thank you very much for your help. It is clear now!
Rgds,
On Tue, Apr 15, 2008 at 4:05 PM, Dan Halperin <[EMAIL PROTECTED]>
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> At hat point can I send the samples (for example from a file with
> > > gr.file_source) and guaran
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
At hat point can I send the samples (for example from a file with
> gr.file_source) and guarantee they will be treated as a 270.8333Ks/
s stream?
> (assuming there will be enough samples to process)
No. They will be treated like a 2Msps stream w
On Tue, Apr 15, 2008 at 3:48 PM, Wireless Monster
<[EMAIL PROTECTED]> wrote:
> ...I understand...
> so... What needs to be done to assure data will be treated as a 270.833Ks/s
> rate?
I feel like we're in an Abbott and Costello routine.
Data is nothing until it's pumped out of a DAC at a specific
...I understand...
so... What needs to be done to assure data will be treated as a 270.833Ks/s
rate?
Thanks!
On Tue, Apr 15, 2008 at 3:31 PM, Brian Padalino <[EMAIL PROTECTED]> wrote:
> On Tue, Apr 15, 2008 at 3:14 PM, Wireless Monster
> <[EMAIL PROTECTED]> wrote:
> > Hi Brian,
> > Thank you for
On Tue, Apr 15, 2008 at 3:14 PM, Wireless Monster
<[EMAIL PROTECTED]> wrote:
> Hi Brian,
> Thank you for your help. Looks good :)
>
> So If I understood correctly I can do the following:
>
> I set the USRP interpolator to 64, so the USRP sink will consume samples at
> a 2MS/s. I add the resampler j
Hi Brian,
Thank you for your help. Looks good :)
So If I understood correctly I can do the following:
I set the USRP interpolator to 64, so the USRP sink will consume samples at
a 2MS/s. I add the resampler just before with a ratio 16/13 so I it consumes
samples with a 1.625MS/s rate. Just before
Don - I ran through all of these updates (autoconf 2.59, automake 1.9.5,
libtool 1.5.22) using the mingwPORT as you suggested. However, I
couldn't get your "sed" command to work properly so just edited
"aclocal" and "autoconf" manually to replace "C:" with "/C/". After
doing all of this, I did ha
Eric Blossom wrote:
They'll be synchronized. There's nothing special that you need to do
assuming that "new block" derives from gr_sync_{block,interpolator,
decimator}
Excellent.
However, because of the group delay in the FIR, there'll be a constant
offset between the two streams. The ea
On Tue, Apr 15, 2008 at 10:55:02AM -0400, George Nychis wrote:
> Hi all,
>
> What I need is the output of GNU Radio's FIR filter (gr.fir_filter_ccc) to
> be synchronized with the raw samples from the USRP into the input of a new
> block.
>
> Like this, where the input to the new block ensures tha
Hi all,
What I need is the output of GNU Radio's FIR filter (gr.fir_filter_ccc)
to be synchronized with the raw samples from the USRP into the input of
a new block.
Like this, where the input to the new block ensures that input[0][N] is
related to input[1][N] ... such that input[M][N] is alw
12 matches
Mail list logo
