[Discuss-gnuradio] External clock with Rev 3: cut traces coming from crystal
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 desolder X2? Thank you, Chris ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP Tx Rate Conversion
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 1.625MS/s rate. Just before that I have the GMSK filter with a interpolation factor of 6 so at the input it is consuming samples at the desired rate 270833.333 Samples/s. 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) Thank you again for your help! Doesn't the resampler have to be followed by a low pass filter to remove the aliased high frequencies that are introduced? @(^.^)@ Ed ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP Tx Rate Conversion
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 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 which is what you > > interpolated your 270.8333Ksps stream to. You will have interpolated > > your original signal by exactly 96/13 which will give you a 2Msps > > stream. > > > > I think you and Brian are experiencing notational confusion with Ks/s. If > you treat the post-processed signal as a 2 Msamples/sec signal then the > output signal will be a 270.733 Ksyms/sec. I believe that the USRP settings > you describe will do just that. > > - -Dan > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.8 (Darwin) > > iEYEARECAAYFAkgFCpoACgkQy9GYuuMoUJ5RJgCfcq8ShxoFNmhvWNLFxET0V1CC > 4nMAoKb4DyL8RyBxWCCntsfMwKZssUoQ > =dC0T > -END PGP SIGNATURE- > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP Tx Rate Conversion
-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 which is what you interpolated your 270.8333Ksps stream to. You will have interpolated your original signal by exactly 96/13 which will give you a 2Msps stream. I think you and Brian are experiencing notational confusion with Ks/s. If you treat the post-processed signal as a 2 Msamples/sec signal then the output signal will be a 270.733 Ksyms/sec. I believe that the USRP settings you describe will do just that. - -Dan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkgFCpoACgkQy9GYuuMoUJ5RJgCfcq8ShxoFNmhvWNLFxET0V1CC 4nMAoKb4DyL8RyBxWCCntsfMwKZssUoQ =dC0T -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP Tx Rate Conversion
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 rate. Lets say it's 64Msps is the exact rate we're going to be feeding some DACs. We know there is an interpolating CIC filter beforehand. We figure we'll do a power of 2 to ensure there is no extra gain added to the signal - so we choose 64. Knowing this information, the stream at the output of the interpolating CIC filter is 64Msps, and the stream going in is 64/64Msps, or 1Msps - then we know we should generate a stream of data that is in fact a 1Msps representation of whatever data we wish. In your case, you wish to make a 270.8333kSps (the S here means Symbols ... also known as a baud) stream into a 1Msps sample stream. With some quick math, I can determine that you need to interpolate by the exact value of 48/13. This has your data (270.8333kSymbols/sec) at a sample rate of 1Msample/sec. The lesson here is to never mix the terminology of sample and symbol (or baud) rate. Is it more clear as to what you're doing now? Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP Tx Rate Conversion
...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 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 that I have the GMSK filter > with > > a interpolation factor of 6 so at the input it is consuming samples at > the > > desired rate 270833.333 Samples/s. > > > > 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 which is what you > interpolated your 270.8333Ksps stream to. You will have interpolated > your original signal by exactly 96/13 which will give you a 2Msps > stream. > > Brian > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP Tx Rate Conversion
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 just before with a ratio 16/13 so I it consumes > samples with a 1.625MS/s rate. Just before that I have the GMSK filter with > a interpolation factor of 6 so at the input it is consuming samples at the > desired rate 270833.333 Samples/s. > > 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 which is what you interpolated your 270.8333Ksps stream to. You will have interpolated your original signal by exactly 96/13 which will give you a 2Msps stream. Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP Tx Rate Conversion
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 that I have the GMSK filter with a interpolation factor of 6 so at the input it is consuming samples at the desired rate 270833.333 Samples/s. 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) Thank you again for your help! On Mon, Apr 14, 2008 at 8:55 PM, Brian Padalino <[EMAIL PROTECTED]> wrote: > On Mon, Apr 14, 2008 at 8:03 PM, Wireless Monster > <[EMAIL PROTECTED]> wrote: > > Hi All, > > > > I am new to gnuradio and the USRP board and I have a basic question. > > > > I want to transmit a GSM signal. Once It is encoded I have a 270833.333 > > symbols/sec signal. Then, it is up-converted (x8) and GMSK filtered, so > I > > get a 2.1666 Ms/s complex signal. > > > > Now the question: How to adapt this rate to the DAC converter on the > USRP > > board? > > Well, if you don't use your x8 upconversion, you can get away with a > rational resampling (I believe). > > Taking 270833.333, and upconverting by 3x makes the sample rate > 812500. If you then rationally resample this by 16/13, you get a nice > 1Msps signal which you can upconvert by a nice power of 2 for the > USRP. > > Try it out and let us know how it works out? > > Brian > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MinGW install problem
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 have to delete my gnuradio-3.1.2 directory and start over from "tar -zxf gnuradio-3.1.2.tar.gz", but from there on I just followed the current instructions. Everything seems to have built properly and things seem to be working. Two other things: 1) I recalled mention of NumPy as a requirement vice Numeric so installed it a while back, but notice your instructions still reference Numeric. Is NumPy not required? 2) I happened to notice the required SDL version changed from 1.2.11 to 1.2.13 so it might be worth highlighting that fact in the instructions. Thanks a lot for your help! Rob -- Message: 6 Date: Sat, 12 Apr 2008 19:21:47 -0400 From: "Don Ward" <[EMAIL PROTECTED]> Subject: Re: [Discuss-gnuradio] MinGW install problem To: "Walker, Robert CIV NSWC Crane,WCE Aviation Systems Staff" <[EMAIL PROTECTED]>, Cc: [EMAIL PROTECTED] Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Don Ward wrote: ... GNU Radio 3.1.2 requires several MSYS/MinGW packages that were not required by earlier releases. You need the following: - autoconf 2.59 (or later) - automake 1.9.5 (or later) - libtool 1.5 (or later) ... I also needed an extra step to work around a problem in automake: aclocal_exe=`which aclocal` sed s,C:/,/C/,g $aclocal_exe > aclocal.tmp mv -f aclocal.tmp $aclocal_exe You may need to repeat the above step, substituting "autoconf" for "aclocal". You may need to start a new MSYS shell for the new versions of the above tools to be seen. These added requirements are also required for building from the svn repository. They are needed because the Windows versions of libtool do not know how to track interlibrary dependencies. Let me know if these instructions work or if they need corrections. When we get a set that works, I will add them to the wiki. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] possible to synchronize two input streams?
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 easiest way to fix that is to use
gr.delay in the path that is currently straight through.
Right, this is what I wasn't sure if it would be automatically corrected
for such that input[0][N] would be related to input[1][N]... but as you
stated, it's input[0][N] is related to input[1][N+delta].
I'm assuming this delay is the delay the history of the FIR filter,
which is the length of the coefficients. If it's not, let me know...
otherwise I shall continue on!
Thanks!
George
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] possible to synchronize two input streams?
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 that input[0][N] is
> related to input[1][N] ... such that input[M][N] is always valid for both
> input streams:
> http://skrbl.com/72178738
>
> Then, the output streams need to be synchronized also... but I can ensure
> this in work() as long as my input streams are synchronized.
>
> I re-went through the how to write a block guide, and I'm still a little
> iffy on whether or not this is possible. Forecast() specifies the
> relationship between input and output of the streams, but I'm wondering if
> it can force the block to wait for an equal number of input items on both
> streams?
>
> I'd greatly appreciate any feedback.
>
> Thanks!
> George
They'll be synchronized. There's nothing special that you need to do
assuming that "new block" derives from gr_sync_{block,interpolator,
decimator}
However, because of the group delay in the FIR, there'll be a constant
offset between the two streams. The easiest way to fix that is to use
gr.delay in the path that is currently straight through.
Eric
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] possible to synchronize two input streams?
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 always valid for both input streams: http://skrbl.com/72178738 Then, the output streams need to be synchronized also... but I can ensure this in work() as long as my input streams are synchronized. I re-went through the how to write a block guide, and I'm still a little iffy on whether or not this is possible. Forecast() specifies the relationship between input and output of the streams, but I'm wondering if it can force the block to wait for an equal number of input items on both streams? I'd greatly appreciate any feedback. Thanks! George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
