Re: [Discuss-gnuradio] Support wideband(20MHz) OFDM transmitting/receiving using RawOFMD and USRP N210
Could I know your current achieved bandwidth of OFDM communication over GNURadio on your platform? On Tue, Aug 7, 2012 at 9:55 AM, wrote: > ** > > On 07 Aug 2012 10:49, Nathan West wrote: > > > Agreed, which is why there is general advice, like enabling real-time > scheduling for non-root users: > http://lists.gnu.org/archive/html/discuss-gnuradio/2010-07/msg00463.html > > You should also run volk_profile : > http://gnuradio.org/redmine/projects/gnuradio/wiki/Volk > > And if you think the link between the USRP and your PC is an issue you > shouldn't use any kind of hub/switch. > > -Nathan > > I've found that if you're consistently running out of steam, enabling > real-time scheduling doesn't help. > > > > -- Alex, *Dreams can come true – just believe.* ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Support wideband(20MHz) OFDM transmitting/receiving using RawOFMD and USRP N210
On Tue, Aug 7, 2012 at 9:12 AM, wrote: > ** > > On 06 Aug 2012 17:59, Alex Zhang wrote: > > Just state, I was using the tunnel.py instead of the rawOFDM to do the > test. Seems nobody declared good bitrate within this community, although I > have asked for many times. > > > > -- > > Alex, > *Dreams can come true – just believe.* > > Nobody has answered because there is no single answer. Your achievable > performance depends on too many factors for anyone to come up with a > reasonable answer. > Yes, I agree with you that there are many factors to impact the performance. So I keep asking what is the best performance has been achieved within the community, and then I can compare with them to find out the possible space to improve the bandwidth supported. What I just need is just an concrete number for benchmark. If any guy claims the good result, I will know I still can do something to beat the limit. > Different computers, with very different performance levels, different OS > distributions with different optimizations in different parts of the > kernel. And that's ignoring any of the path distortions that may be > present between your radios. > > The fact is that general-purpose operating systems aren't well-optimized > for real-time, high-bandwidth, digital signal processing, even on systems > where the "raw" compute power would seem to be adequate. The path lengths > (in terms of number of executed instructions) between data sources and the > calculations are much longer than they would be in a compute environment > optimized for the job. > > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- Alex, *Dreams can come true – just believe.* ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] hanging on top_block.stop
Upgrading to boost 1.48 fixed the problem.
Thanks again,
Ben
On Tue, Aug 7, 2012 at 2:43 PM, Ben Reynwar wrote:
> Great, thanks. I'm using boost 1.46.1 so hopefully this will go away
> once I upgrade to 1.47.
>
> On Tue, Aug 7, 2012 at 2:20 PM, Don Ward wrote:
>> You don't say what OS or version of boost you are using, but it sounds like
>> an old problem. Try looking at
>> http://lists.gnu.org/archive/html/discuss-gnuradio/2011-12/msg00098.html in
>> the mailing list archives.
>>
>> -- Don W.
>>
>>
>> - Original Message - From: "Ben Reynwar"
>> To: "discuss-gnuradio Discussion Group"
>> Sent: Tuesday, August 07, 2012 1:31 PM
>> Subject: [Discuss-gnuradio] hanging on top_block.stop
>>
>>
>>> Hi all,
>>>
>>> The following script hangs for me about 1 time in 10 on the call to
>>> top_block.stop.
>>> Drilling in a bit, it appears to get stuck on a call to 'interrupt' of
>>> a boost::thread instance on line 91 of gruel/src/lib/thread_group.cc.
>>> Has anyone else had this problem?
>>>
>>> Cheers,
>>> Ben
>>>
>>> import time
>>> from gnuradio import gr
>>>
>>> def execute():
>>>tb = gr.top_block()
>>>src = gr.vector_source_c([1], True)
>>>snk = gr.null_sink(gr.sizeof_gr_complex)
>>>tb.connect(src, snk)
>>>tb.start()
>>>time.sleep(0.01)
>>>print("**About to Stop***")
>>>tb.stop()
>>>print("**Stopped***")
>>>
>>> if __name__ == "__main__":
>>>execute()
>>>
>>> ___
>>> 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] hanging on top_block.stop
You don't say what OS or version of boost you are using, but it sounds like
an old problem. Try looking at
http://lists.gnu.org/archive/html/discuss-gnuradio/2011-12/msg00098.html in
the mailing list archives.
-- Don W.
- Original Message -
From: "Ben Reynwar"
To: "discuss-gnuradio Discussion Group"
Sent: Tuesday, August 07, 2012 1:31 PM
Subject: [Discuss-gnuradio] hanging on top_block.stop
Hi all,
The following script hangs for me about 1 time in 10 on the call to
top_block.stop.
Drilling in a bit, it appears to get stuck on a call to 'interrupt' of
a boost::thread instance on line 91 of gruel/src/lib/thread_group.cc.
Has anyone else had this problem?
Cheers,
Ben
import time
from gnuradio import gr
def execute():
tb = gr.top_block()
src = gr.vector_source_c([1], True)
snk = gr.null_sink(gr.sizeof_gr_complex)
tb.connect(src, snk)
tb.start()
time.sleep(0.01)
print("**About to Stop***")
tb.stop()
print("**Stopped***")
if __name__ == "__main__":
execute()
___
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] preload a signal onto USRP
If you really needed to use a USRP as a standalone signal generator you could probably encode the signal into a hardware block on the FPGA, depending on how much in the way of resources are left unused. It would be much more work than the file source method mentioned earlier. Why do you want it preloaded? Low latency? -R C On Tue, Aug 7, 2012 at 4:38 PM, Anisha Gorur wrote: > Hello All, > I have a bit of a strange question. Is it possible to somehow preload a > signal (it would be periodic) onto a USRP so that I would only have to send > a signal saying "begin transmit", and it would do so, without sending > anything besides the "begin transmit" message over the Ethernet cable? I've > been searching around and I haven't found anyone who wanted to do something > like this. > > Thanks, > Anisha > > ___ > 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] preload a signal onto USRP
You can preload the signal to a file. Thereafter, just use the flow graph: File source (repeat) --> USRP. Thanks, Nazmul On Tue, Aug 7, 2012 at 4:38 PM, Anisha Gorur wrote: > Hello All, > I have a bit of a strange question. Is it possible to somehow preload a > signal (it would be periodic) onto a USRP so that I would only have to send > a signal saying "begin transmit", and it would do so, without sending > anything besides the "begin transmit" message over the Ethernet cable? I've > been searching around and I haven't found anyone who wanted to do something > like this. > > Thanks, > Anisha > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- Muhammad Nazmul Islam Graduate Student Electrical & Computer Engineering Wireless Information & Networking Laboratory Rutgers, USA. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] preload a signal onto USRP
Hello All, I have a bit of a strange question. Is it possible to somehow preload a signal (it would be periodic) onto a USRP so that I would only have to send a signal saying "begin transmit", and it would do so, without sending anything besides the "begin transmit" message over the Ethernet cable? I've been searching around and I haven't found anyone who wanted to do something like this. Thanks, Anisha ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] hanging on top_block.stop
On Tue, Aug 7, 2012 at 10:31 AM, Ben Reynwar wrote:
> Hi all,
>
> The following script hangs for me about 1 time in 10 on the call to
> top_block.stop.
> Drilling in a bit, it appears to get stuck on a call to 'interrupt' of
> a boost::thread instance on line 91 of gruel/src/lib/thread_group.cc.
> Has anyone else had this problem?
>
> Cheers,
> Ben
>
> import time
> from gnuradio import gr
>
> def execute():
> tb = gr.top_block()
> src = gr.vector_source_c([1], True)
> snk = gr.null_sink(gr.sizeof_gr_complex)
> tb.connect(src, snk)
> tb.start()
> time.sleep(0.01)
> print("**About to Stop***")
> tb.stop()
> print("**Stopped***")
>
> if __name__ == "__main__":
> execute()
Also, if I write the same logic in straight C++ it works fine.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] hanging on top_block.stop
Hi all,
The following script hangs for me about 1 time in 10 on the call to
top_block.stop.
Drilling in a bit, it appears to get stuck on a call to 'interrupt' of
a boost::thread instance on line 91 of gruel/src/lib/thread_group.cc.
Has anyone else had this problem?
Cheers,
Ben
import time
from gnuradio import gr
def execute():
tb = gr.top_block()
src = gr.vector_source_c([1], True)
snk = gr.null_sink(gr.sizeof_gr_complex)
tb.connect(src, snk)
tb.start()
time.sleep(0.01)
print("**About to Stop***")
tb.stop()
print("**Stopped***")
if __name__ == "__main__":
execute()
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [USRP-users] usrp n210 cantenna radar
Try http://www.l-com.com/. A new packaged 1W amplifier for $130 seems reasonable to me. Anything over 1W is "...available only for export, military, licensed amateur radio and OEM component sales and are not offered for general sale within the USA". Evan Merewether - 575-640-5582 -Original Message- From: usrp-users-boun...@lists.ettus.com [mailto:usrp-users-boun...@lists.ettus.com] On Behalf Of Juha Vierinen Sent: Tuesday, August 07, 2012 7:13 AM To: gnuradio mailing list; usrp-us...@lists.ettus.com Subject: [USRP-users] usrp n210 cantenna radar Hi, I recently saw a picture of a nice little cantenna radar designed and built by Gregory Charvat from MIT (cantenna = waveguide antenna built from a tin can). His web page is here: http://www.glcharvat.com/Dr._Gregory_L._Charvat_Projects/Cantenna_Radar.html This seemed like a cool little project, so I hacked something similar myself. The only difference is that I used a N210 and an SBX daughterboard for signal generation and reception. Here is a video: http://youtu.be/OIKmCStuw2c I'm working now to get some transmission coding to be able to get range gates too. Does anybody know of any cheap 2.4 GHz amplifiers that would increase power from 0.1 W to 1 or maybe 10 W? juha ___ USRP-users mailing list usrp-us...@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com - No virus found in this message. Checked by AVG - www.avg.com Version: 2012.0.2197 / Virus Database: 2437/5182 - Release Date: 08/06/12 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Support wideband(20MHz) OFDM transmitting/receiving using RawOFMD and USRP N210
On 07 Aug 2012 10:49, Nathan West wrote: > Agreed, which is why there is general advice, like enabling real-time scheduling for non-root users: http://lists.gnu.org/archive/html/discuss-gnuradio/2010-07/msg00463.html [1] > > You should also run volk_profile : http://gnuradio.org/redmine/projects/gnuradio/wiki/Volk [2] > > And if you think the link between the USRP and your PC is an issue you shouldn't use any kind of hub/switch. > > -Nathan I've found that if you're consistently running out of steam, enabling real-time scheduling doesn't help. Links: -- [1] http://lists.gnu.org/archive/html/discuss-gnuradio/2010-07/msg00463.html [2] http://gnuradio.org/redmine/projects/gnuradio/wiki/Volk ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Support wideband(20MHz) OFDM transmitting/receiving using RawOFMD and USRP N210
On 06 Aug 2012 17:59, Alex Zhang wrote: > Just state, I was using the tunnel.py instead of the rawOFDM to do the test. Seems nobody declared good bitrate within this community, although I have asked for many times. > > -- > > Alex, > _Dreams can come true - just believe._ Nobody has answered because there is no single answer. Your achievable performance depends on too many factors for anyone to come up with a reasonable answer. Different computers, with very different performance levels, different OS distributions with different optimizations in different parts of the kernel. And that's ignoring any of the path distortions that may be present between your radios. The fact is that general-purpose operating systems aren't well-optimized for real-time, high-bandwidth, digital signal processing, even on systems where the "raw" compute power would seem to be adequate. The path lengths (in terms of number of executed instructions) between data sources and the calculations are much longer than they would be in a compute environment optimized for the job. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] usrp n210 cantenna radar
Hi, I recently saw a picture of a nice little cantenna radar designed and built by Gregory Charvat from MIT (cantenna = waveguide antenna built from a tin can). His web page is here: http://www.glcharvat.com/Dr._Gregory_L._Charvat_Projects/Cantenna_Radar.html This seemed like a cool little project, so I hacked something similar myself. The only difference is that I used a N210 and an SBX daughterboard for signal generation and reception. Here is a video: http://youtu.be/OIKmCStuw2c I'm working now to get some transmission coding to be able to get range gates too. Does anybody know of any cheap 2.4 GHz amplifiers that would increase power from 0.1 W to 1 or maybe 10 W? juha ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Audio sink does not throttle sample flow
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 <>___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
