Send Discuss-gnuradio mailing list submissions to
address@hiddenTo subscribe or unsubscribe via the World Wide Web, visit
https://lists.gnu.org/mailman/listinfo/discuss-gnuradioor, via email, send a message with
subject or body 'help' to
address@hiddenYou can reach the person managing the list at
address@hiddenWhen replying, please edit your Subject line so it is more specific
than "Re: Contents of Discuss-gnuradio digest..."
Today's Topics:
1. Re: WX GUI Widgets Under C++ (Josh Blum)
2. Re g : spectrum sensing code (sumitstop)
3. Re: WX GUI Widgets Under C++ (Daniel Labarowski)
4. When Modifying a Block Do We Have to Recompile Everything?
(Frederick Lee)
5. Re: When Modifying a Block Do We Have to Recompile
Everything? (Tom Rondeau)
6. Re: WX GUI Widgets Under C++ (Josh Blum)
7. Re: SBX Board re-synchonization feature. (Josh Blum)
8. Re: gri_control_loop::set_frequency() Possible Error?
(Tom Rondeau)
9. Question about Spectrum Sense codes (cdong8812)
10. Re: Question about digital_ofdm_mapper_bcv class and d_msg
variable (Tom Rondeau)
11. Re: Audio sink does not throttle sample flow (Tom Rondeau)
12. Re: When Modifying a Block Do We Have to Recompile
Everything? (Frederick Lee)
13. UHD I/O Pins (sibar002)
14. Re: When Modifying a Block Do We Have to Recompile
Everything? (Frederick Lee)
15. Re: UHD I/O Pins (Josh Blum)
16. Re: Re g : spectrum sensing code (sreeraj r)
17.
simple parallel output shift register (abdullah unutmaz)
18. Re: Question about Spectrum Sense codes (sumitstop)
19. Re: Setting the XCVR2450 Bandwidth (Michael Hill)
20. Re: Question about digital_ofdm_mapper_bcv class and d_msg
variable (Lampros Katsikas)
21. Re: Re g : spectrum sensing code (sumitstop)
----------------------------------------------------------------------
Message: 1
Date: Tue, 21 Aug 2012 09:05:01 -0700
From: Josh Blum <
address@hidden>
To:
address@hiddenSubject: Re: [Discuss-gnuradio] WX GUI Widgets Under C++
Message-ID: <
address@hidden>
Content-Type:
text/plain; charset=ISO-8859-1
On 08/21/2012 08:46 AM, Daniel Labarowski wrote:
> I was wondering if there was any way to use WX GUI Widgets, such as the
> scope and fft plot, in a C++ flowgraph? Are any examples or other
> resources available? I have been designing these flowgraphs based on the
> dial tone example. Thanks ahead of time!
>
The existing WX widgets and windows in gnuradio are exclusively python.
You would have to involve python in your application to use them.
Now, the QTGui widgets, those are written and can be used in C++
-josh
------------------------------
Message: 2
Date: Tue, 21 Aug 2012 09:22:49 -0700 (PDT)
From: sumitstop <
address@hidden>
To:
address@hiddenSubject: [Discuss-gnuradio] Re g : spectrum sensing code
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=us-ascii
Hi Community,
Question - 1
I was working with the UHD version of spectrum sensing code.
I have USRP2 with me. I learnt that USRP2 can achieve 50MHz of RF bandwidth
with 8 bit samples and 25MHz of RF bandwidth with 16 bit samples.
I wanted to know how does this information translates while passing min_freq
ans max_freq parameters to the spectrum sensing code. Does it mean (max_freq
- min_freq) = 25MHz.
Please correct me if I am wrong :teeth:
Question - 2
Why the minimum center frequency is set as follows :
self.min_center_freq = self.min_freq +
self.freq_step/2
Why it simply doesn't take the minimum frequency as we provided. Setting the
max_center_freq I understood somehow.
Question - 3
In non UHD version of spectrum sensing code the adc_rate was fixed fro
USRP-1 i.e. 64M and that was used to calculate usrp_rate while in UHD
version of the same code usrp_rate is calculated by the sampling rate we
give.
I was wondering how does the code manages to work with devices of different
sampling rates i.e. USRP-1 with 64M USRP2 with 100M
Context : I am trying to scan WLAN channels 1, 6, 11 continuously. So I have
to keep working with a total bandwidth of 76 MHz
-----
Sumit Kr.
Research Assistant
Communication Research center
IIIT Hyderabad
India
--
View this message in context:
http://old.nabble.com/Reg-%3A-spectrum-sensing-code-tp34330101p34330101.htmlSent from the GnuRadio mailing list archive at Nabble.com.
------------------------------
Message: 3
Date: Tue, 21 Aug 2012 13:23:08 -0400
From: Daniel Labarowski <
address@hidden>
To:
address@hiddenSubject: Re: [Discuss-gnuradio] WX GUI Widgets Under C++
Message-ID: <
address@hidden>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Josh,
Thanks for the reply. The QT Gui Time Sink sounds like it might be
similar to the scope and the Sink sounds like it might be an fft, but I
can't
seem to get them to run in GRC. I am receiving the error below. It
looks like these blocks make a call to top layout which doesn't exist? I
built gnuradio using the build-gnuradio script on the 25th of last month.
-Dan
*Time Sink*
> Traceback (most recent call last):
> File "top_block.py", line 59, in <module>
> tb = top_block()
> File "top_block.py", line 41, in __init__
> self.top_layout.addWidget(self._qtgui_time_sink_x_0_win)
> File "top_block.py", line 94, in __getattr__
> return getattr(self._tb, name)
> AttributeError: 'gr_top_block_sptr' object has no attribute 'top_layout'
*Sink*
> Traceback (most recent call last):
> File "top_block.py", line 67, in <module>
> tb = top_block()
> File "top_block.py", line 46, in __init__
>
self.top_layout.addWidget(self._qtgui_sink_x_0_win)
> File "top_block.py", line 94, in __getattr__
> AttributeError: 'gr_top_block_sptr' object has no attribute 'top_layout'
> return getattr(self._tb, name)
On 08/21/2012 12:05 PM, Josh Blum wrote:
> The existing WX widgets and windows in gnuradio are exclusively python.
> You would have to involve python in your application to use them.
>
> Now, the QTGui widgets, those are written and can be used in C++
>
> -josh
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120821/c2f11368/attachment.html>
------------------------------
Message: 4
Date: Tue, 21 Aug 2012
11:27:39 -0700
From: Frederick Lee <
address@hidden>
To:
address@hiddenSubject: [Discuss-gnuradio] When Modifying a Block Do We Have to
Recompile Everything?
Message-ID:
<CAOEHxm0uX1oLfH0zaeL_trCa4DML-J0rtp=
address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
HI,
I wanted to modify a block and use it. Will I have to recompile everything
or can I just use it without compiling?
I'm still new to Linux, so if I need to compile can someone provide a link
to some instructions to do so?
Thanks,
Frederick
--------------
next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120821/bdef083a/attachment.html>
------------------------------
Message: 5
Date: Tue, 21 Aug 2012 17:48:51 -0400
From: Tom Rondeau <
address@hidden>
To: Frederick Lee <
address@hidden>
Cc:
address@hiddenSubject: Re: [Discuss-gnuradio] When Modifying a Block Do We Have to
Recompile Everything?
Message-ID:
<CA+SzT6gADvJJFbXKyT+ZG7XQrYx3RvQbqun0=R75FR3poX+
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On Tue, Aug 21, 2012 at 2:27 PM, Frederick Lee <
address@hidden> wrote:
> HI,
>
> I wanted to modify a block and use it. Will I have to recompile everything
> or can I just use it without compiling?
> I'm still new to Linux, so if I need to compile can someone provide a link
> to some instructions to do so?
>
> Thanks,
>
> Frederick
Frederick,
You will have to recompile and reinstall, but not everything. If you
are modifying a single block, you can just rebuild from that
components directory. You want to do the entire component to make sure
SWIG is initiated again to
rebuild the Python interface. But this is
much quicker than rebuilding from the top source directory that would
walk through all directories (it won't rebuild them, but the walking
takes time).
So if you are changing a block in gr-digital, you can just:
cd gr-digital
make
make test (or ctest)
sudo make install
Tom
------------------------------
Message: 6
Date: Tue, 21 Aug 2012 14:51:30 -0700
From: Josh Blum <
address@hidden>
To:
address@hiddenSubject: Re: [Discuss-gnuradio] WX GUI Widgets Under C++
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On
08/21/2012 10:23 AM, Daniel Labarowski wrote:
> Josh,
> Thanks for the reply. The QT Gui Time Sink sounds like it might be
> similar to the scope and the Sink sounds like it might be an fft, but I
> can't seem to get them to run in GRC. I am receiving the error below. It
> looks like these blocks make a call to top layout which doesn't exist? I
> built gnuradio using the build-gnuradio script on the 25th of last month.
>
Try changing the options block to qt gui. -josh
> -Dan
>
> *Time Sink*
>> Traceback (most recent call last):
>> File "top_block.py", line 59, in <module>
>> tb = top_block()
>> File "top_block.py", line 41, in __init__
>> self.top_layout.addWidget(self._qtgui_time_sink_x_0_win)
>> File "top_block.py", line 94, in __getattr__
>> return
getattr(self._tb, name)
>> AttributeError: 'gr_top_block_sptr' object has no attribute 'top_layout'
>
> *Sink*
>> Traceback (most recent call last):
>> File "top_block.py", line 67, in <module>
>> tb = top_block()
>> File "top_block.py", line 46, in __init__
>> self.top_layout.addWidget(self._qtgui_sink_x_0_win)
>> File "top_block.py", line 94, in __getattr__
>> AttributeError: 'gr_top_block_sptr' object has no attribute 'top_layout'
>> return getattr(self._tb, name)
>
>
> On 08/21/2012 12:05 PM, Josh Blum wrote:
>> The existing WX widgets and windows in gnuradio are exclusively python.
>> You would have to involve python in your application to use them.
>>
>> Now, the QTGui widgets, those are written and can be used in
C++
>>
>> -josh
>>
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
>
address@hidden>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
------------------------------
Message: 7
Date: Tue, 21 Aug 2012 14:51:46 -0700
From: Josh Blum <
address@hidden>
To:
address@hiddenSubject: Re: [Discuss-gnuradio] SBX Board re-synchonization feature.
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On 08/21/2012 07:30 AM, guelord ingala wrote:
> Hi,
> I'm designing a beamforming network. I want to know if it is now
> possible to align LOs from multiple SBX and usrp boards. It was said
> from Ettus Research website that the re-synchronization feature in UHD
> using SBX boards will be released in 2012. Could you please confirm if
> it is implementable.
> Regards.
> Dominique.
>
http://files.ettus.com/uhd_docs/manual/html/sync.html#align-los-in-the-front-end-sbx-wbx-n-seriesThe set/clear_command_time are exposed for the UHD source and sink
blocks. You can do this in gnradio with c++ or
python.
-josh
------------------------------
Message: 8
Date: Tue, 21 Aug 2012 17:52:02 -0400
From: Tom Rondeau <
address@hidden>
To: Frederick Lee <
address@hidden>
Cc:
address@hiddenSubject: Re: [Discuss-gnuradio] gri_control_loop::set_frequency()
Possible Error?
Message-ID:
<CA+SzT6g55SjALAe=KWei_eiBmyDS6QQSuVBEmjJU3ZLEqE0+
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Aug 16, 2012 at 7:11 PM, Frederick Lee <
address@hidden> wrote:
> Hi,
>
> I was looking at the gri_control_loop.cc file and notices the
> set_frequency() function seemed a little odd. Here's what it looked like.
>
> void
> gri_control_loop::set_frequency(float freq)
> {
> if(freq > d_max_freq)
> d_freq = d_min_freq;
> else if(freq < d_min_freq)
> d_freq = d_max_freq;
> else
> d_freq = freq;
> }
>
> This doesn't seem logical to me. Shouldn't the it be "d_freq = d_max_freq"
> in the if statement and "d_freq = d_min_freq" in the else if statement?
> The frequency_limit() function has it the way I stated
>
> void
> gri_control_loop::frequency_limit()
> {
> if (d_freq > d_max_freq)
> d_freq =
d_max_freq;
> else if (d_freq < d_min_freq)
> d_freq = d_min_freq;
> }
>
> Regards,
>
> Frederick
Frederick,
Yes, that it s a bit odd. It's due to the historical nature of that
loop. We wanted the frequency to wrap around in some of the early
loops as opposed to just railing against the edges. I think the idea
is to let it keep searching in the bandwidth for a lock.
Now, that might not be the right answer. I'm not entirely sure what
is, though. If you just rail it against the max or min frequency,
you're just sitting there doing nothing. Is that better or worse than
forcing it around to the other side? Frankly, if the frequency of the
signal that you are trying to track is outside of the loop, you're
kind of hosed anyways. Would holding it stable at the max/min be
more
appropriate?
Tom
------------------------------
Message: 9
Date: Tue, 21 Aug 2012 14:56:14 -0700 (PDT)
From: cdong8812 <
address@hidden>
To:
address@hiddenSubject: [Discuss-gnuradio] Question about Spectrum Sense codes
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=us-ascii
Hi,
I'm currently working on a project about spectrum sensing and I went over
the USRP_Spectrun_Sense codes. But I've got a question about the content of
m.data. Because in the while loop, when you print out m.data, it's FFT_Size
of samples for each center frequency(Not a single
value). If I want to get
the FFT result for each FFT bin, is it correct to do like this: print
m.center_freq sum(m.data) in each loop. Any help would be appreciated.
Regards,
Chen Dong
--
View this message in context:
http://old.nabble.com/Question-about-Spectrum-Sense-codes-tp34331807p34331807.htmlSent from the GnuRadio mailing list archive at Nabble.com.
------------------------------
Message: 10
Date: Tue, 21 Aug 2012 18:00:34 -0400
From: Tom Rondeau <
address@hidden>
To: Lampros Katsikas <
address@hidden>
Cc:
address@hiddenSubject: Re: [Discuss-gnuradio] Question about digital_ofdm_mapper_bcv
class and d_msg variable
Message-ID:
<CA+
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On Wed, Aug 15, 2012 at 4:17 AM, Lampros Katsikas
<
address@hidden> wrote:
> Hello everyone,
>
> In the current implementation of the digital_ofdm_mapper_bcv::work() method
> only one packet of 528 size(in other words d_msg->length() == 528) is
> consumed each time in order to create a
symbol.
> I tried to modify the method to consume more of those packets but it still
> not works.
> So the question is if there is a way to change the packet size of the msg
> (d_msg->length()) from 528 to another integer.I could not find where this
> value is given yet.
>
> Thans in advance,
> Lampros.
You can change the lengths of most parts of the symbol and packet. If
you run the benchmark_tx.py script with '-h', you'll see the list of
options. The '-s' allows you to specify the length of the packet
(default = 400 bytes), the number of subcarriers (--fft-length), the
number of used subcarriers (--occupied-tones) and the length of the
cyclic prefix (--cp-length).
You should be able to make the OFDM code work on more than one symbol
at a time, which should help a bit in the performance. The
book-keeping starts to get nasty, so to make it easier on us when we
put
this together, we decided to get it right by only using one symbol
at a time.
Tom
------------------------------
Message: 11
Date: Tue, 21 Aug 2012 18:09:23 -0400
From: Tom Rondeau <
address@hidden>
To: Felix Wunsch <
address@hidden>
Cc:
address@hiddenSubject: Re: [Discuss-gnuradio] Audio sink does not throttle sample
flow
Message-ID:
<CA+
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On Mon, Aug 13, 2012 at 12:25 PM, Felix Wunsch
<
address@hidden> wrote:
>
> Am 13.08.2012 13:33, schrieb Tom Rondeau:
>>
>> On Mon, Aug 13, 2012 at 5:05 AM, Felix Wunsch
>> <
address@hidden> wrote:
>>>
>>> Am 12.08.2012 19:19, schrieb Tom Rondeau:
>>>
>>>> On Tue, Aug 7, 2012 at 6:22 AM, Felix Wunsch
>>>> <
address@hidden> wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> I recently wrote a block for decoding DRM AAC streams. For testing I
>>>>> put
>>>>> together a small flow graph consisting of a wav source, encoder block,
>>>>> decoder block, (rational) resampler and an audio sink (an image of the
>>>>> flow
>>>>> graph is attached).
>>>>>
>>>>> When I now run this flow graph, the audio is correctly decoded, but the
>>>>> output is not throttled to 44.1 kHz as it should be. It seems to be
>>>>> running
>>>>> at full speed. I also connected a resampler and an audio sink directly
>>>>> to
>>>>> the wav source and there the
output is correct.
>>>>>
>>>>> I use default values for the audio sink (alsa, 44.1 kHz), GNU Radio
>>>>> 3.5.1
>>>>> and xubuntu 11.10.
>>>>>
>>>>> Any hints why this is happening and how to solve this?
>>>>>
>>>>> Best regards,
>>>>> Felix Wunsch
>>>>
>>>> Felix,
>>>>
>>>> I know that the audio sink will throttle the flow graph. What evidence
>>>> do you have that it's not or that it's running at full speed? Is it
>>>> the sound coming from the audio? My first guess is that there's a
>>>> misunderstanding somewhere of the actual sample rate. You're
>>>> resampling by almost 2x, which means you expect the signal coming from
>>>> the decoder to be 44.1e3/2. Is
that right?
>>>>
>>>> Tom
>>>
>>>
>>> Hi Tom,
>>>
>>> thanks for your reply.
>>>
>>> My first evidence was in fact the sound coming from the audio that is
>>> running at a very high speed. However, the pitch seems to be normal. The
>>> flow graph is set to "run to completion" and processes a 3 min wav-file
>>> in
>>> about 15 sec.
>>>
>>> The signal coming from the decoder has a sample rate of 24 kHz. I
>>> verified
>>> that by writing the decoder output into a file and using aplay for
>>> playback
>>> with -r 24000. At this point, the sound is still normal.
>>>
>>> The next steps are in detail:
>>> - Type conversion short->float
>>> - multiply const (1/32768) for range
adjustment
>>> - rational resampler( interp: 441, decim: 240)
>>> - audio sink (44.1kHz)
>>>
>>> Did I configure the resampler correctly? I left taps blank and fractional
>>> bandwidth at 0.
>>>
>>> I also attached a file sink to the output of the resampler and tried to
>>> play
>>> it with aplay using -r 44100. It shows the same behaviour like the audio
>>> sink (normal pitch, very fast playback).
>>>
>>> Best regards,
>>> Felix
>>
>> Felix,
>>
>> That looks like you're doing everything correctly. I wonder if it's an
>> issue with the sound card, seeing as you're getting the same behavior
>> with aplay. Can you set the output device? If you can use pulseaudio,
>> set the device string to 'pulse' and see what that does.
Otherwise,
>> try 'plughw:0,0'. They might handle the sampling rate settings better.
>>
>> Tom
>
> Hi Tom,
>
> I don't think that it's a sound card issue as I successfully used the
> audio sink before. Nevertheless, I tried pulse and plughw:0,0 to be
> sure. Results are exactly the same. I also attached an audio sink
> directly to my wav file source at the beginning of the flow graph and
> this one is working properly.
>
> While I was trying the different setups, I noticed that the file sizes
> of my two file sink outputs are not as expected. The decoder output in
> my special case is 8.7 MB while the resampler output is no more than 1.1
> MB. I would have expected a size of 8.7 MB * resampling rate, about 15 MB.
>
> To me, it looks like I'm losing lots of samples (about 7 out of 8) in
> the rational resampler block.
>
>
Felix
Sorry, Felix, lost track of things last week. Are you still having
issues or have you solved it?
Since you're seeing different files sizes, yes, something is going
wrong with you're resampling. Can you try to plug in the pfb_arbitrary
resampler? You can use the one in blks2 (or
filter.pfb.arb_resampler_xxf if you are working on a branch with
gr-filter already) with which you can just tell it the resampling rate
you want (as a float) and it will create a filter for you that passes
the entire spectrum of the input signal.
Tom
------------------------------
Message: 12
Date: Tue, 21 Aug 2012 15:45:08 -0700
From: Frederick Lee <
address@hidden>
To: Tom Rondeau <
address@hidden>
Cc:
address@hiddenSubject: Re: [Discuss-gnuradio] When Modifying a Block Do We Have to
Recompile Everything?
Message-ID:
<CAOEHxm0+fcAhgfjE+
address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
On Tue, Aug 21, 2012 at 2:53 PM, Frederick Lee <
address@hidden>wrote:
>
>> Frederick,
>>
>> You will have to recompile and reinstall, but not everything. If you
>> are modifying a single block, you can just rebuild from that
>> components directory. You want to do the entire
component to make sure
>> SWIG is initiated again to rebuild the Python interface. But this is
>> much quicker than rebuilding from the top source directory that would
>> walk through all directories (it won't rebuild them, but the walking
>> takes time).
>>
>> So if you are changing a block in gr-digital, you can just:
>>
>> cd gr-digital
>> make
>> make test (or ctest)
>> sudo make install
>>
>> Tom
>>
>
> Thanks a lot Tom. It's great to know that I don't have to go through all
> the directories because I was using the gnuradio_build option on the
> build-gnuradio script to rebuild and it takes some time to complete. :)
>
> Thanks again
>
> Frederick
>
> Sorry for posting again, but when I try the above instructions the make
command fails. The error I get it
this:
make: *** No targets specified and no makefile found. Stop.
Does the build-gnuradio script put makefiles into the directories for you?
If not, is it possible to get the makefile else where or find a way around
it?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120821/cf02382c/attachment.html>
------------------------------
Message: 13
Date: Tue, 21 Aug 2012 15:45:08 -0700 (PDT)
From: sibar002 <
address@hidden>
To:
address@hiddenSubject: [Discuss-gnuradio] UHD I/O
Pins
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=us-ascii
Hello,
I would like to control the io_rx[15 - 0] pins on the basic_rx
daugtherboard. I am able to set them as either input or output pins by using
the set_pin_ctrl() function. I would like to input a signal into one of
these pins and be able to read the value. I have been reading the different
daughterboard .cc files in the host directory, but I havent found any code
that does this. I would greatly appreciate any help or advice on how to do
this. Thank you for your time and help.
Sam
--
View this message in context:
http://old.nabble.com/UHD-I-O-Pins-tp34332005p34332005.htmlSent from the GnuRadio mailing list
archive at Nabble.com.
------------------------------
Message: 14
Date: Tue, 21 Aug 2012 15:53:20 -0700
From: Frederick Lee <
address@hidden>
To: Tom Rondeau <
address@hidden>
Cc:
address@hiddenSubject: Re: [Discuss-gnuradio] When Modifying a Block Do We Have to
Recompile Everything?
Message-ID:
<CAOEHxm2JeCU_yvY6kN4TYCa05mtwfy-kJ3f7cWhpp6a9Xbc2=
address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
On Tue, Aug 21, 2012 at 3:45 PM, Frederick Lee <
address@hidden>wrote:
>
>
> On Tue, Aug 21, 2012 at 2:53 PM, Frederick Lee <
address@hidden>wrote:
>
>>
>>> Frederick,
>>>
>>> You will have to recompile and reinstall, but not everything. If you
>>> are modifying a single block, you can just rebuild from that
>>> components directory. You want to do the entire component to make sure
>>> SWIG is initiated again to rebuild the Python interface. But this is
>>> much quicker than rebuilding from the top source directory that would
>>> walk through all directories (it won't rebuild them, but the walking
>>> takes time).
>>>
>>> So if you are changing a block in gr-digital, you can
just:
>>>
>>> cd gr-digital
>>> make
>>> make test (or ctest)
>>> sudo make install
>>>
>>> Tom
>>>
>>
>> Thanks a lot Tom. It's great to know that I don't have to go through all
>> the directories because I was using the gnuradio_build option on the
>> build-gnuradio script to rebuild and it takes some time to complete. :)
>>
>> Thanks again
>>
>> Frederick
>>
>> Sorry for posting again, but when I try the above instructions the make
> command fails. The error I get it this:
>
> make: *** No targets specified and no makefile found. Stop.
>
> Does the build-gnuradio script put makefiles into the directories for you?
> If not, is it possible to get the makefile else where or find a way around
> it?
>
> Nevermind,
I found the correct directory. I was looking in the
gnuradio/gr-digital directroy instead of the gnuradio/build/gr-digital
directory.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120821/2769047c/attachment.html>
------------------------------
Message: 15
Date: Tue, 21 Aug 2012 16:09:16 -0700
From: Josh Blum <
address@hidden>
To:
address@hiddenSubject: Re: [Discuss-gnuradio] UHD I/O Pins
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On 08/21/2012 03:45 PM, sibar002 wrote:
>
> Hello,
>
> I would like to control the io_rx[15 - 0] pins on the basic_rx
> daugtherboard. I am able to set them as either input or output pins by using
> the set_pin_ctrl() function. I would like to input a signal into one of
You will need to set GPIO input
http://files.ettus.com/uhd_docs/doxygen/html/classuhd_1_1usrp_1_1dboard__iface.html#a377aa6291e0a77cbdf74c58762799c73And call read gpio:
http://files.ettus.com/uhd_docs/doxygen/html/classuhd_1_1usrp_1_1dboard__iface.html#ad623a6a90d91eb4e0e047b9da56d1a98> these pins and be able to read the value. I have been reading the different
> daughterboard .cc files in the host directory, but I havent found any code
> that does this. I would greatly appreciate any help or advice on how to do
> this. Thank you for your time and help.
>
> Sam
>
------------------------------
Message: 16
Date: Wed, 22 Aug 2012 15:17:22 +0800 (SGT)
From: sreeraj r <
address@hidden>
To: sumitstop <
address@hidden>,
"
address@hidden" <
address@hidden>
Subject: Re: [Discuss-gnuradio] Re g : spectrum sensing code
Message-ID:
<
address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
>Question - 1
>
>I was working with the UHD version of spectrum sensing code.
>
>I have USRP2 with me. I learnt that USRP2 can achieve 50MHz of RF bandwidth
>with 8 bit samples and 25MHz of RF bandwidth with 16 bit samples.
>
>I wanted to know how does this information translates while passing min_freq
>ans max_freq parameters to the
spectrum sensing code. Does it mean (max_freq
>- min_freq) = 25MHz.
>
>Please correct me if I am wrong :teeth:
As far as I understand spectrum sensing code is used for wideband spectrum analysis, that is
to scan across wide RF bands which USRP is not able to analyze at a time. So obviously
max_freq - min_freq > 25 MHz .
e.g Conider you have to analyze the spectrum from 400 MHz to 500 MHz. You can keep
min_freq = 400 MHz and max_freq = 500MHz. If you have configured USRP sample rate
to get 25 MHz bandwidth, ideally one round of scan will be complete by 4 tuning steps.
(practically 6 steps as the code is using 25% overlap to reduce non-linearity in DDC response).
Firas posted a detailed explanation of the code in the mailing list long back. You can find it
here http://www.ruby-forum.com/topic/174437.
>Question - 2
>Why the minimum center frequency is set as follows
:
>
>self.min_center_freq = self.min_freq + self.freq_step/2
>Why it simply doesn't take the minimum frequency as we provided. Setting the
>max_center_freq I understood somehow.
e.g. Scan range 10MHz to 40 MHz
???? USRP1 B/W = 8MHz
???? First tuning step is with centre freq 14Mhz (10+8/2 ideally) which will cover the bandwidth from 10 to 18 Mhz
>Question - 3
>In non UHD version of spectrum sensing code the adc_rate was fixed fro
>USRP-1 i.e. 64M and that was used to calculate usrp_rate while in UHD
>version of the same code usrp_rate is calculated by the sampling rate we
>give.
>I was wondering how does the code manages to work with devices of different
>sampling rates i.e. USRP-1 with 64M USRP2 with 100M
sampling rate ----> Bandwidth? ----> feq_step
>Context : I am trying to scan WLAN channels 1, 6, 11 continuously. So I
have
>to keep working with a total bandwidth of 76 MHz
Check the tuning delay of the device you are using and make sure that you are not losing any data during the sweeping process.I may be wrong somewhere. Please go through Firas's explanation which will make things clear.
regards
Sreeraj Rajendran
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120822/6ce9a93c/attachment.html>
------------------------------
Message: 17
Date: Wed, 22 Aug 2012 04:24:08 -0700 (PDT)
From: abdullah unutmaz <
address@hidden>
To: discuss-gnuradio Discussion Group <
address@hidden>
Subject: [Discuss-gnuradio] simple parallel output shift register
Message-ID:
<
address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Greetings everybody,
I have been trying to design a simple parallel output shift register, use gr.buffer & gr.buffer_reader.
But I am having the error:
------------------------------------------------------------------------------------------------------------------------------------------------------------
File "dataST.py", line 61, in <module>
??? tb = top_block()
? File "dataST.py", line 40, in __init__
???
self.my_buffer=gr.buffer(11,gr.sizeof_char*1,self.my_h)
? File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/gnuradio_core_runtime.py", line 312, in buffer
??? return _gnuradio_core_runtime.buffer(*args, **kwargs)
TypeError: in method 'buffer', argument 3 of type 'gr_block_sptr'
------------------------------------------------------------------------------------------------------------------------------------------------------------
You can see all of my program below:
from gnuradio import eng_notation
from gnuradio import gr
from gnuradio.eng_option import eng_option
from gnuradio.gr import firdes
from grc_gnuradio import wxgui as grc_wxgui
from optparse import OptionParser
import wx
import time
class top_block(grc_wxgui.top_block_gui):
??? def __init__(self):
??????????? grc_wxgui.top_block_gui.__init__(self, title="Top Block")
??????????? _icon_path =
"/usr/share/icons/hicolor/32x32/apps/gnuradio-grc.png"
??????????? self.SetIcon(wx.Icon(_icon_path, wx.BITMAP_TYPE_ANY))
??????????? ##################################################
??????????? # Variables
??????????? ##################################################
??????????? self.samp_rate = samp_rate = 1000000
??????????? ##a################################################
??????????? # Blocks
??????????? ##################################################
??????????? self.my_vec_src = gr.vector_source_b((1, 1, 1, 1,1, 1, 1, 1,1, 1, 1), True, 1)
??????????? #self.my_vec_snk = gr.vector_sink_b(1)
??????????? self.my_thro = gr.throttle(gr.sizeof_char*1, samp_rate)
??????????? self.my_h = gr.head(gr.sizeof_char*1, 11)
???????????
??????????? # buffer
???????????
??????????? self.my_buffer=gr.buffer(11,gr.sizeof_char*1,self.my_h)
???????????
self.my_buffer_reader=gr.buffer_reader(self.my_buffer,11)
???????????
??????????? ##################################################
??????????? # Connections
??????????? ##################################################
??????????? self.connect((self.my_vec_src, 0), (self.my_thro, 0))
??????????? self.connect((self.my_thro, 0), (self.my_h, 0))
??????????? self.connect((self.my_h, 0), (self.my_buffer, 0))
???????????
??? def get_samp_rate(self):
??? ??? return self.samp_rate
??? def set_samp_rate(self, samp_rate):
??? ??? self.samp_rate = samp_rate
if __name__ == '__main__':
??? parser = OptionParser(option_class=eng_option, usage="%prog: [options]")
??? (options, args) = parser.parse_args()
??? tb = top_block()
??? tb.Run(True)
??????? while(True):
??????????? #time.sleep(10)
??????????? if(tb.my_buffer.done()):
???????????????
my_data=tb.my_buffer_reader.read_pointer()
??????????????? print "data: ",my_data
---------------------------------------------------------------------------------------------------------------------------------------------------
Is there anyway to use gr_buffer & gr_buffer_reader properly to design a simple parallel output shift register?
I searched not only the other discussions in the forum, but also examples I can find. I also tried to find a
use of gr_buffer in python files, also in doxygen, nothing... Third argument , "link" , is confusing, I tried to make a connection
between gr_buffer and gr_throttle instead of gr_head, unfortunately it does not work, too.
What should I do?
Thanks in advance,
Abdullah
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120822/3c680539/attachment.html>
------------------------------
Message: 18
Date: Wed, 22 Aug 2012 05:21:40 -0700 (PDT)
From: sumitstop <
address@hidden>
To:
address@hiddenSubject: Re: [Discuss-gnuradio] Question about Spectrum Sense codes
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=us-ascii
Hi Chen,
I was also doing the same as you asked. Since energy equals the
sum of all
FFT coefficients hence summation of all FFT bins looks reasonable to me.
:teeth:
cdong8812 wrote:
>
> Hi,
> I'm currently working on a project about spectrum sensing and I went over
> the USRP_Spectrun_Sense codes. But I've got a question about the content
> of m.data. Because in the while loop, when you print out m.data, it's
> FFT_Size of samples for each center frequency(Not a single value). If I
> want to get the FFT result for each FFT bin, is it correct to do like
> this: print m.center_freq sum(m.data) in each loop. Any help would be
> appreciated.
>
> Regards,
>
>
> Chen Dong
>
-----
Sumit Kr.
Research Assistant
Communication Research center
IIIT Hyderabad
India
--
View this message in context:
http://old.nabble.com/Question-about-Spectrum-Sense-codes-tp34331807p34334088.htmlSent from the GnuRadio mailing list archive at Nabble.com.
------------------------------
Message: 19
Date: Wed, 22 Aug 2012 22:41:00 +0930
From: Michael Hill <
address@hidden>
To:
address@hiddenCc: "
address@hidden" <
address@hidden>
Subject: Re: [Discuss-gnuradio] Setting the XCVR2450 Bandwidth
Message-ID:
<
address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Thanks Josh,
I've still been toying with this though.. and aren't really having any
success.
E.g. if I pick a Tx bandwidth of 24MHz.. and transmit
and use 8bit I&Q samples transmitted at 50MHz.. then shouldn't I see some
signs of the filter?
What should I be looking for on my spec amp?
I assume by baseband filter, that you mean this is a digital filter that
applies what I send from the CPU to the USRP..
Cheers
-Michael
On Wed, Jul 11, 2012 at 9:09 AM, Josh Blum <
address@hidden> wrote:
>
>
> On 07/08/2012 04:28 AM, Michael Hill wrote:
> > Hi,
> >
> >
This is a two part question
> >
> > 1) What are the XCVR2450 bandwidth options?
> > I've looked at the website and discussion list threads on the matter and
> > seen different answers on what the the bandwidth options are for the
> > XCVR2450 daughterboard.
> > The spec sheets seem to indicate different answers too.. which muddle me
> > further as I'm unsure if i'm reading them wrong.
> > Can someone clarify for me what they are? Have there been two revisions
> of
> > this hardware of something?
> >
>
> Maybe there is some confusion about specifying the bandwidth of a
> baseband filter. See this for available rates.
> 20 MHz means +/- 10 MHz about the center of the baseband signal.
>
http://files.ettus.com/uhd_docs/manual/html/dboards.html#xcvr-2450>
> > 2) How do I se the bandwidth?
> > I'm trying to use the Bandwidth block on the UHD_Sink.
> > However I don't get any confirmation messages or indicators if i've set
> it
> > wrong.. how can I check?
> >
>
> RX defaults to 19MHz and TX 24MHz. You really cant see the filter
> profile unless sample rate > filter BW
>
> -josh
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120822/e9ea7a2b/attachment.html>
------------------------------
Message: 20
Date: Wed, 22 Aug 2012 17:49:33 +0300
From: Lampros Katsikas <
address@hidden>
To: Tom Rondeau <
address@hidden>
Cc:
address@hiddenSubject: Re: [Discuss-gnuradio] Question about digital_ofdm_mapper_bcv
class and d_msg variable
Message-ID:
<CAHCBcJE=
address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Thank you very much for your reply but this is not what i was looking for...
Its my fault because didn't tell you what exactly i would like to do!
So,
i don't want just to run the benchmark_tx.py to see its behaviour but i
would like if possible to give the packet_size as a parameter or even set
it statically with another size in order to handle bigger packets at the
work method of the digital_ofdm_mapper_bcv class.
I have already checked the gr_buffer and gr_msg_queue files from
gnuradio_core folder but i havent seen anything yet.
Thank you in advance,
Lampros.
2012/8/22 Tom Rondeau <
address@hidden>
> On Wed, Aug 15, 2012 at 4:17 AM, Lampros Katsikas
> <
address@hidden> wrote:
> > Hello everyone,
> >
> > In the current implementation of the digital_ofdm_mapper_bcv::work()
> method
> > only one packet of 528 size(in other
words d_msg->length() == 528) is
> > consumed each time in order to create a symbol.
> > I tried to modify the method to consume more of those packets but it
> still
> > not works.
> > So the question is if there is a way to change the packet size of the msg
> > (d_msg->length()) from 528 to another integer.I could not find where this
> > value is given yet.
> >
> > Thans in advance,
> > Lampros.
>
> You can change the lengths of most parts of the symbol and packet. If
> you run the benchmark_tx.py script with '-h', you'll see the list of
> options. The '-s' allows you to specify the length of the packet
> (default = 400 bytes), the number of subcarriers (--fft-length), the
> number of used subcarriers (--occupied-tones) and the length of the
> cyclic prefix (--cp-length).
>
> You should be able to make the
OFDM code work on more than one symbol
> at a time, which should help a bit in the performance. The
> book-keeping starts to get nasty, so to make it easier on us when we
> put this together, we decided to get it right by only using one symbol
> at a time.
>
> Tom
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120822/a52ce572/attachment.html>
------------------------------
Message: 21
Date: Wed, 22 Aug 2012 08:52:32 -0700 (PDT)
From: sumitstop <
address@hidden>
To:
address@hiddenSubject: Re: [Discuss-gnuradio] Re g : spectrum sensing code
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=UTF-8
Hi Sreeraj,
Thanks for the reply.
sreeraj r wrote:
>
>
>
>>Question - 1
>>
>>I was working with the UHD version of spectrum sensing code.
>>
>>I have USRP2 with me. I learnt that USRP2 can achieve 50MHz of RF
bandwidth
>>with 8 bit samples and 25MHz of RF bandwidth with 16 bit samples.
>>
>>I wanted to know how does this information translates while passing
min_freq
>>ans max_freq parameters to the spectrum sensing code. Does it mean
(max_freq
>>- min_freq) =
25MHz.
>>
>>Please correct me if I am wrong :teeth:
>
> As far as I understand spectrum sensing code is used for wideband spectrum
> analysis, that is
> to scan across wide RF bands which USRP is not able to analyze at a time.
> So obviously
> max_freq - min_freq > 25 MHz .
>
> e.g Conider you have to analyze the spectrum from 400 MHz to 500 MHz. You
> can keep
> min_freq = 400 MHz and max_freq = 500MHz. If you have configured USRP
> sample rate
> to get 25 MHz bandwidth, ideally one round of scan will be complete by 4
> tuning steps.
> (practically 6 steps as the code is using 25% overlap to reduce
> non-linearity in DDC response).
>
> Firas posted a detailed explanation of the code in the mailing list long
> back. You can find it
> here http://www.ruby-forum.com/topic/174437.
>
@@@@@@@@@@@@@@@@@@@@@@@@@@
> I already went through the code explanation by Firas. So according to your
> saying :
> To scan 400MHz to 500MHz I have to take 4 tuning steps. Center frequency
> of tuning steps shall be 412.5MHz, 437.5MHz, 462.5MHz and 487.5 (for the
> time being lets ignore the FFT overlaping)
> And this tuning step size is calculated according to : freq_step = 0.75 *
> usrp_rate
> where USRP rate is the sampling rate we give.
> I have a basic doubt. Since the processing bandwidth at a time is 25MHz,
> so shall I pass sampling rate = 2*bandwidth i.e. for this case 2*25Mhz =
> 50MSPS (Pl correct if I am wrong)
>>Question - 2
>
>>Why the minimum center frequency is set as follows :
>>
>>self.min_center_freq = self.min_freq + self.freq_step/2
>
>>Why it simply doesn't take the minimum frequency as we provided.
Setting
the
>>max_center_freq I understood somehow.
>
> e.g. Scan range 10MHz to 40 MHz
> ???? USRP1 B/W = 8MHz
> ???? First tuning step is with centre freq 14Mhz (10+8/2 ideally) which
> will cover the bandwidth from 10 to 18 Mhz
> @@@@@@@@@@@
> Thanks , I was so intuitive :)
> @@@@@@@@@@@
>>Question - 3
>
>>In non UHD version of spectrum sensing code the adc_rate was fixed fro
>>USRP-1 i.e. 64M and that was used to calculate usrp_rate while in UHD
>>version of the same code usrp_rate is calculated by the sampling rate we
>>give.
>
>>I was wondering how does the code manages to work with devices of
different
>>sampling rates i.e. USRP-1 with 64M USRP2 with 100M
>
> sampling rate ----> Bandwidth? ----> feq_step
>
>>Context : I am trying to scan WLAN channels 1, 6, 11
continuously. So I
have
>>to keep working with a total bandwidth of 76 MHz
>
> Check the tuning delay of the device you are using and make sure that you
> are not losing any data during the sweeping process.I may be wrong
> somewhere. Please go through Firas's explanation which will make things
> clear.
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> Any standard process you know to check the tuning delay.
>
>
> regards
> Sreeraj Rajendran
> _______________________________________________
> Discuss-gnuradio mailing list
>
address@hidden>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
>
-----
Sumit Kr.
Research
Assistant
Communication Research center
IIIT Hyderabad
India
--
View this message in context:
http://old.nabble.com/Reg-%3A-spectrum-sensing-code-tp34330101p34335158.htmlSent from the GnuRadio mailing list archive at Nabble.com.
------------------------------
_______________________________________________
Discuss-gnuradio mailing list
address@hiddenhttps://lists.gnu.org/mailman/listinfo/discuss-gnuradioEnd of Discuss-gnuradio Digest, Vol 117, Issue 24
*************************************************