[Discuss-gnuradio] N210, About Decimation Rate
Hello List, I have a short question about the decimation rate of the USRP N210 : Since I know that the decimation rate of the N-Series is supposed to be programmable and that one was able to change it using the usrp_rx_cfile.py-script, why is this option missing in the UHD-Version of this script? Regards Sebastian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] usrp2_rx_cfile.py issue
I tried almost all things. I also tried without -s.
Well, the current situation is I am getting the three kinds of IQ data.
1. both of the IQ valid signal is achieved.
2. Either I or Q is valid, the other one is a dead signal (showing '0',
zero values)
3. Both of them are dead signal ('0' values).
I dont know why I am getting the zero. There should be a value even for
noise. It should not be zero.
Any idea?
On Wed, Nov 23, 2011 at 10:10 AM, Tom Rondeau wrote:
> On Mon, Nov 21, 2011 at 6:31 AM, Hasan Rajib Imam wrote:
>
>> Hello Tom & Nick,
>>
>> Thanks for your help. I am here to ask another question.
>>
>> I am using the following command
>> sudo python usrp2_rx_cfile.py -f 800M -N 1000 -d 100 -s -v output.dat
>>
>> After that, I converted the .dat file using octave command
>> (read_complex_binary).
>>
>> However, the values I am getting are ambiguous.
>> I am getting lots of 0 (zeros) and lots of Nan (dont know what does it mean
>> though)..I have no idea about it.
>>
>> Here is the snapshot of what I get. I would really appreciate if somebody
>> can give any idea about this. Thank you.
>>
>>
> Doesn't the -s option output shorts? When you use the read_complex_binary,
> it's expecting it as complex floats (32-bit float I, 32-bit float Q). Try
> capturing without the -s and try again.
>
> You might also have to turn up the receiver gain.
>
> Tom
>
>
>
>>
>> --snapshot---
>> (9.183409485952689e-41,0)
>> (NaN,NaN)
>> (NaN,NaN)
>> (NaN,NaN)
>> (NaN,NaN)
>> (NaN,9.183409485952689e-41)
>> (NaN,NaN)
>> (NaN,9.183409485952689e-41)
>> (NaN,NaN)
>> (NaN,NaN)
>> (9.183409485952689e-41,0)
>> (NaN,9.183409485952689e-41)
>> (9.183409485952689e-41,0)
>> (9.183409485952689e-41,9.183409485952689e-41)
>> (NaN,NaN)
>> (9.183409485952689e-41,0)
>> (NaN,NaN)
>> (0,9.183409485952689e-41)
>> (NaN,NaN)
>> (NaN,9.183409485952689e-41)
>> (NaN,NaN)
>> (NaN,9.183409485952689e-41)
>> (0,9.183269356106256e-41)
>> (9.183409485952689e-41,9.183409485952689e-41)
>> (9.183409485952689e-41,0)
>> (9.183409485952689e-41,0)
>> (9.183409485952689e-41,0)
>> (0,0)
>> (0,0)
>> (0,0)
>> (0,0)
>> (0,0)
>> (0,0)
>> (0,0)
>> (0,0)
>> (0,0)
>> (0,0)
>> (0,0)
>> (0,0)
>> (0,0)
>> (0,0)
>> (0,0)
>> (0,0)
>> (0,0)
>> (0,0)
>>
>>
>>
>> On Sat, Nov 19, 2011 at 12:16 AM, Tom Rondeau wrote:
>>
>>> On Thu, Nov 17, 2011 at 6:41 PM, Hasan Rajib Imam
>>> wrote:
>>>
Hello Nick,
Thanks for your reply.
"you can use Gnuradio blocks such as the decimating FIR filter to
decimate additionally by however much you like."
Could you please tell me how can I do the above thing? Actually I am
very new to gnuradio. I will really appreciate your help.
Thanks.
>>>
>>>
>>> Hasan,
>>>
>>> You can use the gr.fir_filter_XXX(decim, taps) or
>>> gr.fft_filter_XXX(decim, taps). The taps are generally defined using
>>> gr.firdes.low_pass_2(gain, sample rate, bw, transition, attenuation,
>>> window). The 'decim' parameter for these blocks is an integer.
>>>
>>> fft_filter:
>>> http://gnuradio.org/doc/doxygen/classgr__fft__filter__ccc.html
>>>
>>> fir_filter:
>>> http://gnuradio.org/doc/doxygen/classgr__fir__filter__ccc.html
>>>
>>> firdes:
>>> http://gnuradio.org/doc/doxygen/classgr__firdes.html
>>>
>>> Tom
>>>
>>>
>>>
>>>
>>>
On Fri, Nov 18, 2011 at 1:29 AM, Nick Foster wrote:
> On Thu, Nov 17, 2011 at 8:28 AM, Nick Foster wrote:
> > On Thu, Nov 17, 2011 at 2:33 AM, hasanimam
> wrote:
> >>
> >> Hello all,
> >>
> >> I am here once again and would like to bother you a bit.
> >> I am using the usrp2_rx_cfile.py command to get the IQ data from
> usrp2. I am
> >> using the following command
> >>
> >> sudo python usrp2_rx_cfile.py -f 800M -d 496 -s -v -N 10
> >> /home/gnuradio4/Desktop/observed_data/test.dat
> >>
> >> And I am getting the following output:
> >>
> >> Network interface: eth0
> >> USRP2 address: 00:50:c2:85:35:7d
> >> Using RX d'board id 0x0053
> >> Rx gain: 15.75
> >> Rx baseband frequency: 800M
> >> Rx DDC frequency: 0
> >> Rx residual frequency: 0
> >> Rx decimation rate: 512
> >> Rx sample rate: 195.312k
> >> Receving 10 samples
> >> Writing 16-bit complex shorts
> >> Output filename: /home/gnuradio4/Desktop/observed_data/test.dat
> >>
> >> In the above, it shows that the sample rate is 195.312k. I want to
> raise
> >> this rate but it seems that decimation rate has a limit upto 512 so
> i cant
> >> do that.
> >> Can you suggest me any other way to raise the sample rate?
> >> In fact I want the time difference between each sample to be around
> 100us,
> >> but sample rate 195k gives me 5us.
> >
> > "Decimation" means the ratio by which the 100MHz main clock is
> > divided. 100MHz / 512 = 195.312kHz. Try using a lower decimation.
>
> Oh, I think I misunderstood your
Re: [Discuss-gnuradio] usrp2_rx_cfile.py issue
On 24/11/11 05:38 AM, Hasan Rajib Imam wrote:
> I tried almost all things. I also tried without -s.
> Well, the current situation is I am getting the three kinds of IQ data.
> 1. both of the IQ valid signal is achieved.
> 2. Either I or Q is valid, the other one is a dead signal (showing
> '0', zero values)
> 3. Both of them are dead signal ('0' values).
>
> I dont know why I am getting the zero. There should be a value even
> for noise. It should not be zero.
>
> Any idea?
>
Why do you not think that zero is valid?
These I/Q signals are voltage-samples of sinusoidal functions, which
cross zero.
--
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] usrp2_rx_cfile.py issue
Hello Leech,
>Why do you not think that zero is valid?
>These I/Q signals are voltage-samples of sinusoidal functions, which
cross zero.
Would you please explain this in a little bit more detail.
In fact I need some strong reason that zero values can be used as value
i.e. the signal is not dead.
On Thu, Nov 24, 2011 at 8:55 PM, Marcus D. Leech wrote:
> On 24/11/11 05:38 AM, Hasan Rajib Imam wrote:
> > I tried almost all things. I also tried without -s.
> > Well, the current situation is I am getting the three kinds of IQ data.
> > 1. both of the IQ valid signal is achieved.
> > 2. Either I or Q is valid, the other one is a dead signal (showing
> > '0', zero values)
> > 3. Both of them are dead signal ('0' values).
> >
> > I dont know why I am getting the zero. There should be a value even
> > for noise. It should not be zero.
> >
> > Any idea?
> >
> Why do you not think that zero is valid?
>
> These I/Q signals are voltage-samples of sinusoidal functions, which
> cross zero.
>
>
> --
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
--
Hasan Rajib Imam
University of Electro-Communication, Japan
1st year Masters Student
Email: shuvo1...@gmail.com
Contact No: (+81)80-5004-5931
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP N210 Benchmarks.
Hi again Thank you very much, we expect our thesis will be available from some time next year, we will add it to the academic section. The work we have done so far have pointed us to the daughterboard mixer. All mixers have problems causing harmonics, and our research so far has shown us that this is the big problem. The work with gain adjusting the I Q channels in the drivers give us an idea we might be right ;) We have spent a good while describing what frequencies the osclilator on the daughterboard can supply. When in auto mode, the UHD driver will try to select a frequency that is offset, so that an actual direct up/down conversion does not take place. This is what is normally known as the "Superheterodyne radio". However, because of the division of labour between the mixer in the FPGA and the mixer on the daughterboard, the IF frequency selected is often too close to the daughterboard mixer frequency. This results in quite a bit of nasty spikes around the desired signal. There are two ways of testing this: 1: the "scientific") Try sending out a single frequency, a flowgraph of [complex cosine] -> [UHD Sink] was good enough for us. Check out what spurious frequencies are created. You will typically see the wanted signal (f_c +/- f_s), a bit of the _actual_ carrier (f_c) and mirrors of different description. (eg f_c +/- 2*f_s ; f_c -/+ f_s). Increasing the signal frequency(f_s) will reveal which is the oscilator(f_c) and which is the mirror. Page 19 of the AD8349 (mixer for the RFX2400) showed part of this explanation. 2: the "mechanics version") Try other frequencies, maybe you will get lucky ;) One other method might be to write all or parts of the application in C++, that way you should be able to select a mixer frequency far away from the one you need (the N210 FPGA mixer can provide +/- 50MHz offset, i believe the USRP1 can supply +/- 32MHz). This way you should be able to reduce the spurious emissions. The problem using this approach is that you will send the spurious emissions into other parts of the band (the problem with having a narrow signal in a wide-band application). Best Paul 2011/11/23 Justyn Bell > > > On Tue, Nov 22, 2011 at 3:54 PM, Justyn Bell wrote: > >> Hey guys, sorry for the extremely late response. Although identifying >> and solving USRP problems is great, our focus lies in the project at hand. >> >> That being said, the responses on here were great. We tried scaling the >> input signal magnitude and it actually worked very well. The perplexing >> thing, however, is that the more we scale the magnitude, the better the >> observable spectrum got. There was no point in which scaling the magnitude >> didn't show at least a little improvement on the spectrum. I have attached >> the spectrum of our actual P25 waveform with scaling. Also included in >> that figure (yellow) is a signal captured by the USRP that was transmitted >> using an EF Johnson handset with a P25 waveform installed. Clearly the EF >> Johnson's spectrum looks the best, and although we didn't try scaling our >> data further than by .0625, the signal decreases in strength. At some >> point the signal must be too weak to transmit without both compromising the >> SNR and the "granularity" or resolution of the original signal (if that's >> the appropriate word to use). >> >> The biggest thing I am considering is this: we are using a 12.5kHz >> channel on a daughterboard whose range is between 50MHz to 2.2GHz. Is such >> a narrowband signal on such a wide band board problematic? >> >> Although the spectrum looks great when scaled, when we actually test our >> waveform from USRP to USRP we still get bit errors. Again, it's hard to >> say how many because we are utilizing a waveform that is equipped with a >> software vocoder, encryption (small bit errors mean huge losses in packets >> we receive) and forward error correction (should eliminate small bit >> errors). You can see how it is difficult to track down bit errors, but my >> personal opinion is that with forward error correction and the boxes >> sitting no more than 4 feet away from each other, there are enough errors >> to ruin our encrypted messages, and that's just too much. >> >> We would very much like to use the very descriptive images you have >>> provided in our work, if that's okay with you. >> >> >> This is completely fine with all of us here, and thanks again for great >> responses. With the availability of so many USRPs (did I mention we have 2 >> USRP1s with the RFX daughterboards in them?) we can at least narrow things >> down a bit. >> >> >> >> >> >> On Fri, Oct 28, 2011 at 5:08 AM, Marcus D. Leech wrote: >> >>> >>> >>> 2011/10/27 Marcus D. Leech >>> Well, that sounds like the lazy solution, intermodulation products are bad, so just throwing the transmitter power away is not what I'd prefer. But what it points to is an *analog* issue, entirely independant of the CORDIC (which, as I
Re: [Discuss-gnuradio] N210, About Decimation Rate
Forgot the list :) The quick answer is: It's done for you the formula is: decimationrate = iround(tick_rate/sample_rate); where tick_rate = 100e6, and sample_rate is the sample rate you set. It will only allow accurate matches of the decimation rate, otherwise it will tell you what sample rate it wants to go at. Best Paul 2011/11/24 Sebastian Döring > Hello List, > > I have a short question about the decimation rate of the USRP N210 : > > Since I know that the decimation rate of the N-Series is supposed to be > programmable and that one was able to change it using the > usrp_rx_cfile.py-script, why is this option missing in the UHD-Version of > this script? > > Regards > Sebastian > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > -- * - - */* -/* * -/* - * */- * * */*/- */- * */* */- * * -/*/- */* - - *- */- - */- -/* -/* */* - * */* - * - * -/- * - */- - -/- -// ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] usrp2_rx_cfile.py issue
On 11/24/2011 04:08 AM, Hasan Rajib Imam wrote: > Hello Leech, > >> Why do you not think that zero is valid? > >> These I/Q signals are voltage-samples of sinusoidal functions, which > cross zero. > > > Would you please explain this in a little bit more detail. > In fact I need some strong reason that zero values can be used as value > i.e. the signal is not dead. > > As wise man once said: "noobs will be noobs". May I suggest that you start with some simulation to help your understanding. Textbooks too. http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#Flying-Blind -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] usrp2_rx_cfile.py issue
Actually, I am not using any sinusoidal function in this measurement.
So, zero values are not valid I think. I am mostly using the noise
signal so I thought there must be a value.
Here is a sample of what I got.
Any idea would be highly appreciated.
0.0001220703-9.1552734375e-05
0.0001831055-6.103515625e-05
9.1552734375e-050
0.0001220703-0.0001220703
0.0001220703-0.0001220703
6.103515625e-05 -3.0517578125e-05
0 -6.103515625e-05
0.0002441406-6.103515625e-05
0 -6.103515625e-05
0.00027465820
How is it that you can be a masters student in electrical engineering,
and *not* know that noise signals are simply the super-position
of a large series of sinusoidal (or near-sinusoidal) functions? Once
again, the ADCs in an SDR receiver are sampling a complex voltage.
That voltage may occupy any values between {-adc_resolution,
+adc_resolution}. In UHD, the ADC values are scaled (normalized)
into the range {-1.0, +1.0} to make things within the flow-graph
somewhat more general, and allow a certain amount of hardware
independance.
In general, the samples of a noise source will be equally distributed
about 0, and in fact you can confirm this by calculating the
running-average of all your samples--they will tend to converge to 0
(in practice, there will be a small amount of DC offset which
will cause this convergence to be not exactly at zero).
But all this should be in course textbooks, etc. The folks here are
generally kind, and patient, but they can't hope to teach people entire
courses in electrical engineering, RF design, linear and non-linear
circuit theory, and digital signal processing. Although, those who
*do*, generally charge money for it, in one way or another.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] New version of build-gnuradio
Includes two new options: -ut and -gt Which arranges to build particular GIT tags, rather than whatever is at HEAD. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Bug in gr_pll_carriertracking.cc
The last time I did this I had written the routine ;-) Bob On Nov 23, 2011 11:18 AM, "Ben Hilburn" wrote: > Heh, sometimes you have to e-mail a public list before any of it makes > sense. Happens to me all the time =) > > Cheers, > Ben > > > On Wed, Nov 23, 2011 at 8:53 AM, Marcus M wrote: > >> >> >> On Wed, Nov 23, 2011 at 10:12 AM, Marcus M wrote: >> >>> Hi, >>> I have the latest gnuradio release and I think the phase error >>> calculation in gr_pll_carriertracking.cc might be wrong. >>> >>> In Line 107 the phase error is calculated as, >>> error = phase_detector(iptr[i],d_phase); >>> >>> whereas, I think it should be as shown below as the phase error is >>> calculated from the signal that has been corrected in phase. >>> error = phase_detector(optr[i],d_phase); >>> >>> Am I right? >>> >>> My bad. The phase_detector() function returns the difference. Ignore >> this message. >> >> Thanks >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] how to mix two signal
Hi list, I want to send two signal which at different frequency. Can I simply add these two signals' sample to generate a new signal which mix the two signal? Regards! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
