Re: [Discuss-gnuradio] I hate Unity
I have had no problems installing Gnu Radio under Kubuntu. If you already have a potent machine, try that. It gives the added bonus of being much prettier than Gnome ;) Best Regards Paul M. Bendixen 2011/10/17 Ben Hilburn b...@ettus.com N.B.: What follows is obviously all opinion: I can't stand Unity, and the default settings for Gnome 3 drove me nuts. If you are willing to put the effort in, you can install a bunch of extensions that will make it at least approach the usability of Gnome 2. I recommend: http://intgat.tigress.co.uk/rmy/extensions/gnome32.html http://www.webupd8.org/2011/10/official-gnome-shell-extensions.html After installing, restart Gnome, and then use the 'Advanced Settings' menu (which is actually a shortcut to the tool Bob mentioned, gnome-tweak-tool) to enable the extensions you want. I was able to almost achieve what I had in Gnome 2 by doing this - although there are still some annoyances. I really don't understand why Gnome3 took this giant step backwards, and Canonical took Ubuntu even further backwards with Unity. Cheers, Ben On Mon, Oct 17, 2011 at 11:10 AM, Vincenzo Pellegrini wwvi...@gmail.comwrote: Just a couple of lines to cast my ballot in favor of Bob's complaint. I had the same reaction in response to Fedora 15 reception of the Gnome3 thing. That stuff does move too far away from the power-user-desktop concept I've been enjoying for several years as a developer. Also I'm a bit frustrated to have to go after that load of tweaks in order to get a freshly installed system usable. my best regards to everybody there vince 2011/10/17 Alexandru Csete oz9...@gmail.com On Mon, Oct 17, 2011 at 7:28 PM, Tom Rondeau trondeau1...@gmail.com wrote: On Mon, Oct 17, 2011 at 10:39 AM, Robert McGwier rwmcgw...@gmail.com wrote: Install gnome-tweak-tools to get advanced settings for gnome to be able to get your favorite settings after you install gnome-shell. On Mon, Oct 17, 2011 at 10:04 AM, Robert McGwier rwmcgw...@gmail.com wrote: http://tombuntu.com/index.php/2011/10/03/install-gnome-shell-in-ubuntu-11-10/ -- Bob McGwier Facebook: N4HYBob ARS: N4HY Or do what I did: apt-get install gnome-session-fallback and switch to Gnome Classic Mode at the login screen. Removes Unity. I haven't heard anyone say a good thing about Unity. It's an awful environment to develop under. The first thing I do in Ubuntu now is stop using it. I'm now shopping around for another Linux distro if they keep going this way. Tom On Ubuntu 11.04 I have installed Xfce desktop ( http://www.xfce.org/ ) - it is available via the package manager (or by installing xubuntu instead of regular ubuntu). It is similar to Gnome 2 and is very lightweight. Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Vincenzo Pellegrini http://www.youtube.com/user/wwvince1 ___ 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
Re: [Discuss-gnuradio] OFDM Transmiter and receiver by using USRP1
hi Marcus, I am attaching the screen shots and also block diagram of transmitter.. right now i am just trying to look for transmission of OFDM signal via usrp1. As i mentioned earlier in the fft scope plot in gnu radio i see the typical ofdm signal but on the other hand in usrp sink on the spectrum analyser i saw only simple sine wave peak. please have a look and let me know if there is something else do i need to do to generate the proper ofdm signal on the spectrum analyser. /home/hp/Desktop/spectrumoutput.jpeg http://old.nabble.com/file/p32675018/spectrumoutput.jpeg spectrumoutput.jpeg Block diagram in GNU radio /home/hp/Documents/finaltesting.grc http://old.nabble.com/file/p32675018/finaltesting.grc finaltesting.grc Please have a look and suggest me how to fix this problem in order to see the proper ofdm signal on spectrum analyser as well?? Do i need and firm ware update or sumthing on FPGA on usrp1 ??? Looking forward to hear from you. Thanks for your help. Cheers. Marcus D. Leech wrote: On 10/16/2011 05:55 PM, waqasme wrote: Hi Marcus, As i mentioned the flow graph signal blocks i have used in gnu radio companion from that i am getting this out put on FFT sink in GNU radio companion simulation flowgraph which is similar like this If you're trying to embed images, it's not working, and the de-embedded ones on the bottom show only the spectrum of something typical of OFDM, and a spectrum-analyser output that looks like it was set up to sweep from 10Hz to 5GHz (is that what you had in mind?), which would produce only a sharp peak in the middle. We still don't know what your flow-graph(s) look like. -- 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 -- View this message in context: http://old.nabble.com/OFDM-Transmiter-and-receiver-by-using-USRP1-tp32662445p32675018.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Odd behaviur of Fractional Interpolator
I’m using gnuradio-3.3.0 with GRC. I’ve builded a graph with a Complex cosine (8Ms/s of sample rate and 1 MHz of frequency), the fractional interpolator with 12/8 value for interpolation and a FFT sink with 12MS/s of sample rate. (throttle block included). I’m expecting to see a 1MHz cosine with the FFT, but i see a 2.25MHz cosine. If i put 8/12 (the inverse) i see the (correct) 1MHz cosine. Why? If i use the Rational resampler, with interpolation 12 and decimation 8, i see the correct 1MHz cosine. What’s wrong with fractional interpolator block?___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Odd behaviur of Fractional Interpolator
On 18/10/11 01:38 PM, Mattia Rizzi wrote: I’m using gnuradio-3.3.0 with GRC. I’ve builded a graph with a Complex cosine (8Ms/s of sample rate and 1 MHz of frequency), the fractional interpolator with 12/8 value for interpolation and a FFT sink with 12MS/s of sample rate. (throttle block included). I’m expecting to see a 1MHz cosine with the FFT, but i see a 2.25MHz cosine. If i put 8/12 (the inverse) i see the (correct) 1MHz cosine. Why? If i use the Rational resampler, with interpolation 12 and decimation 8, i see the correct 1MHz cosine. What’s wrong with fractional interpolator block? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Because the fractional interpolator takes the *inverse* as the desired fraction--think of it as a decimation ratio. -- 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] Fw: Odd behaviur of Fractional Interpolator
Uhm, so it’s a little bit confusing. Another strange problem is that if i put a 0.64 value of interpolation, and my flow graph is a file souce-fractional interpolator-file sink, and my source file is 1GB of data, i’m expecting a 1GB*1/0.64 output filesize. But when i run the graph i get a 800MB of output filesize, minor than the source file. I cannot undestand this... Thank you. From: Marcus D. Leech Sent: Tuesday, October 18, 2011 7:45 PM To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Odd behaviur of Fractional Interpolator On 18/10/11 01:38 PM, Mattia Rizzi wrote: I’m using gnuradio-3.3.0 with GRC. I’ve builded a graph with a Complex cosine (8Ms/s of sample rate and 1 MHz of frequency), the fractional interpolator with 12/8 value for interpolation and a FFT sink with 12MS/s of sample rate. (throttle block included). I’m expecting to see a 1MHz cosine with the FFT, but i see a 2.25MHz cosine. If i put 8/12 (the inverse) i see the (correct) 1MHz cosine. Why? If i use the Rational resampler, with interpolation 12 and decimation 8, i see the correct 1MHz cosine. What’s wrong with fractional interpolator block? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Because the fractional interpolator takes the *inverse* as the desired fraction--think of it as a decimation ratio. -- 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 mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Odd behaviur of Fractional Interpolator
Sorry, the filesize is my mistake. All okay now. Thank you. From: Mattia Rizzi Sent: Tuesday, October 18, 2011 8:12 PM To: gnu radio Subject: Fw: [Discuss-gnuradio] Odd behaviur of Fractional Interpolator Uhm, so it’s a little bit confusing. Another strange problem is that if i put a 0.64 value of interpolation, and my flow graph is a file souce-fractional interpolator-file sink, and my source file is 1GB of data, i’m expecting a 1GB*1/0.64 output filesize. But when i run the graph i get a 800MB of output filesize, minor than the source file. I cannot undestand this... Thank you. From: Marcus D. Leech Sent: Tuesday, October 18, 2011 7:45 PM To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Odd behaviur of Fractional Interpolator On 18/10/11 01:38 PM, Mattia Rizzi wrote: I’m using gnuradio-3.3.0 with GRC. I’ve builded a graph with a Complex cosine (8Ms/s of sample rate and 1 MHz of frequency), the fractional interpolator with 12/8 value for interpolation and a FFT sink with 12MS/s of sample rate. (throttle block included). I’m expecting to see a 1MHz cosine with the FFT, but i see a 2.25MHz cosine. If i put 8/12 (the inverse) i see the (correct) 1MHz cosine. Why? If i use the Rational resampler, with interpolation 12 and decimation 8, i see the correct 1MHz cosine. What’s wrong with fractional interpolator block? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Because the fractional interpolator takes the *inverse* as the desired fraction--think of it as a decimation ratio. -- 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 mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM Transmiter and receiver by using USRP1
hi Marcus, I am attaching the screen shots and also block diagram of transmitter.. right now i am just trying to look for transmission of OFDM signal via usrp1. As i mentioned earlier in the fft scope plot in gnu radio i see the typical ofdm signal but on the other hand in usrp sink on the spectrum analyser i saw only simple sine wave peak. please have a look and let me know if there is something else do i need to do to generate the proper ofdm signal on the spectrum analyser. /home/hp/Desktop/spectrumoutput.jpeg http://old.nabble.com/file/p32675018/spectrumoutput.jpeg spectrumoutput.jpeg Block diagram in GNU radio /home/hp/Documents/finaltesting.grc http://old.nabble.com/file/p32675018/finaltesting.grc finaltesting.grc Your flow-graph appears to be badly confused about bandwidths and interpolations and sample rates --an interpolation ratio on your USRP1 sink of 100e6 is almost certainly *not* what you had in mind. You probably need to learn more about all of that, and get some better notions of how the OFDM modulator block works. At the very least you'll need to fractionally-interpolate the baseband up to some sample rather that *can* reasonably be further interpolated by the USRP1 hardware. Given how simple this graph currently is, I'd *strongly* suggest that you upgrade your world to UHD, since your investment in the old world is still rather small. -- 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] OFDM Transmiter and receiver by using USRP1
On Oct 18, 2011, at 11:18 AM, Marcus D. Leech mle...@ripnet.com wrote: hi Marcus, I am attaching the screen shots and also block diagram of transmitter.. right now i am just trying to look for transmission of OFDM signal via usrp1. As i mentioned earlier in the fft scope plot in gnu radio i see the typical ofdm signal but on the other hand in usrp sink on the spectrum analyser i saw only simple sine wave peak. please have a look and let me know if there is something else do i need to do to generate the proper ofdm signal on the spectrum analyser. /home/hp/Desktop/spectrumoutput.jpeg http://old.nabble.com/file/p32675018/spectrumoutput.jpeg spectrumoutput.jpeg Block diagram in GNU radio /home/hp/Documents/finaltesting.grc http://old.nabble.com/file/p32675018/finaltesting.grc finaltesting.grc Your flow-graph appears to be badly confused about bandwidths and interpolations and sample rates --an interpolation ratio on your USRP1 sink of 100e6 is almost certainly *not* what you had in mind. You probably need to learn more about all of that, and get some better notions of how the OFDM modulator block works. At the very least you'll need to fractionally-interpolate the baseband up to some sample rather that *can* reasonably be further interpolated by the USRP1 hardware. Given how simple this graph currently is, I'd *strongly* suggest that you upgrade your world to UHD, since your investment in the old world is still rather small. -- Principal Investigator Shirleys Bay Radio Astronomy Consortium As of last night, the 'next' branch of GNU Radio (if you are using git) has the OFDM code and examples rewritten using UHD. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM Transmiter and receiver by using USRP1
Hello Marcus thanks for your reply.. Well the problem is there is not much documentation available on internet on usurp .. Also I am quite new to gnu radio and usrp1 ... I tried to play with interpolation and decimation settings but didnot get the desired ofdm signal .. I am not sure what else I can do to fix this problem . If u know any documentation regarding that please do let me know . U mentioned about UHd but I could not find any UHd blocks in gnu radio .. As I saw in one example someone use UHd .. Iam using Ubuntu 10.10 and gnu radio companion 3.2.2 version .. I will really appreciate if u can guide me how to setup the settings or specs i need for usrp 1 .. Thanks and regards... Marcus D. Leech wrote: hi Marcus, I am attaching the screen shots and also block diagram of transmitter.. right now i am just trying to look for transmission of OFDM signal via usrp1. As i mentioned earlier in the fft scope plot in gnu radio i see the typical ofdm signal but on the other hand in usrp sink on the spectrum analyser i saw only simple sine wave peak. please have a look and let me know if there is something else do i need to do to generate the proper ofdm signal on the spectrum analyser. /home/hp/Desktop/spectrumoutput.jpeg http://old.nabble.com/file/p32675018/spectrumoutput.jpeg spectrumoutput.jpeg Block diagram in GNU radio /home/hp/Documents/finaltesting.grc http://old.nabble.com/file/p32675018/finaltesting.grc finaltesting.grc Your flow-graph appears to be badly confused about bandwidths and interpolations and sample rates --an interpolation ratio on your USRP1 sink of 100e6 is almost certainly *not* what you had in mind. You probably need to learn more about all of that, and get some better notions of how the OFDM modulator block works. At the very least you'll need to fractionally-interpolate the baseband up to some sample rather that *can* reasonably be further interpolated by the USRP1 hardware. Given how simple this graph currently is, I'd *strongly* suggest that you upgrade your world to UHD, since your investment in the old world is still rather small. -- 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 -- View this message in context: http://old.nabble.com/OFDM-Transmiter-and-receiver-by-using-USRP1-tp32662445p32677135.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM Transmiter and receiver by using USRP1
Hello Marcus thanks for your reply.. Well the problem is there is not much documentation available on internet on usurp .. Also I am quite new to gnu radio and usrp1 ... I tried to play with interpolation and decimation settings but didnot get the desired ofdm signal .. I am not sure what else I can do to fix this problem . If u know any documentation regarding that please do let me know . U mentioned about UHd but I could not find any UHd blocks in gnu radio .. As I saw in one example someone use UHd .. Iam using Ubuntu 10.10 and gnu radio companion 3.2.2 version .. I will really appreciate if u can guide me how to setup the settings or specs i need for usrp 1 .. Thanks and regards... Marcus D. Leech wrote: hi Marcus, I am attaching the screen shots and also block diagram of transmitter.. right now i am just trying to look for transmission of OFDM signal via usrp1. As i mentioned earlier in the fft scope plot in gnu radio i see the typical ofdm signal but on the other hand in usrp sink on the spectrum analyser i saw only simple sine wave peak. please have a look and let me know if there is something else do i need to do to generate the proper ofdm signal on the spectrum analyser. /home/hp/Desktop/spectrumoutput.jpeg http://old.nabble.com/file/p32675018/spectrumoutput.jpeg spectrumoutput.jpeg Block diagram in GNU radio /home/hp/Documents/finaltesting.grc http://old.nabble.com/file/p32675018/finaltesting.grc finaltesting.grc Your flow-graph appears to be badly confused about bandwidths and interpolations and sample rates --an interpolation ratio on your USRP1 sink of 100e6 is almost certainly *not* what you had in mind. You probably need to learn more about all of that, and get some better notions of how the OFDM modulator block works. At the very least you'll need to fractionally-interpolate the baseband up to some sample rather that *can* reasonably be further interpolated by the USRP1 hardware. Given how simple this graph currently is, I'd *strongly* suggest that you upgrade your world to UHD, since your investment in the old world is still rather small. -- 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 -- View this message in context: http://old.nabble.com/OFDM-Transmiter-and-receiver-by-using-USRP1-tp32662445p32677136.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM Transmiter and receiver by using USRP1
Hello Marcus thanks for your reply.. Well the problem is there is not much documentation available on internet on usurp .. Also I am quite new to gnu radio and usrp1 ... I tried to play with interpolation and decimation settings but didnot get the desired ofdm signal .. I am not sure what else I can do to fix this problem . If u know any documentation regarding that please do let me know . U mentioned about UHd but I could not find any UHd blocks in gnu radio .. As I saw in one example someone use UHd .. Iam using Ubuntu 10.10 and gnu radio companion 3.2.2 version .. I will really appreciate if u can guide me how to setup the settings or specs i need for usrp 1 .. Thanks and regards... Marcus D. Leech wrote: hi Marcus, I am attaching the screen shots and also block diagram of transmitter.. right now i am just trying to look for transmission of OFDM signal via usrp1. As i mentioned earlier in the fft scope plot in gnu radio i see the typical ofdm signal but on the other hand in usrp sink on the spectrum analyser i saw only simple sine wave peak. please have a look and let me know if there is something else do i need to do to generate the proper ofdm signal on the spectrum analyser. /home/hp/Desktop/spectrumoutput.jpeg http://old.nabble.com/file/p32675018/spectrumoutput.jpeg spectrumoutput.jpeg Block diagram in GNU radio /home/hp/Documents/finaltesting.grc http://old.nabble.com/file/p32675018/finaltesting.grc finaltesting.grc Your flow-graph appears to be badly confused about bandwidths and interpolations and sample rates --an interpolation ratio on your USRP1 sink of 100e6 is almost certainly *not* what you had in mind. You probably need to learn more about all of that, and get some better notions of how the OFDM modulator block works. At the very least you'll need to fractionally-interpolate the baseband up to some sample rather that *can* reasonably be further interpolated by the USRP1 hardware. Given how simple this graph currently is, I'd *strongly* suggest that you upgrade your world to UHD, since your investment in the old world is still rather small. -- 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 -- View this message in context: http://old.nabble.com/OFDM-Transmiter-and-receiver-by-using-USRP1-tp32662445p32677138.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GrBlock
On 10/18/2011 11:18 AM, Jason Bonior wrote:
That worked. We will also try your next version whenever it is available on
Glad to hear it works; I guess zip() cant be used with swig'd vectors on
some platforms (my best guess).
I reworked the code a bit to my liking and it should also fix this
issue. Just grab the latest master branch.
git. We will also begin building some custom blocks using grblock and numpy
and can let you know how it goes if you wish.
of course. It would be interesting to see what you come up with and
possibly how performance compares.
-Josh
Thanks again,
Jason
On Tue, Oct 18, 2011 at 9:38 AM, Josh Blum j...@joshknows.com wrote:
On 10/18/2011 06:54 AM, Jason Bonior wrote:
We added some print statements to try and narrow down the problem. This
is
what we changed:
def pointer_to_ndarray(addr, dtype, nitems):
print pointer_to_ndarray() start
class array_like:
print pointer_to_ndarray array_like class start
__array_interface__ = {
'data' : (addr, False),
'typestr' : dtype.base.str,
'descr' : dtype.base.descr,
'shape' : (nitems,) + dtype.shape,
'strides' : None,
'version' : 3
}
print pointer_to_ndarray array_like class end
print pointer_to_ndarray() end
return numpy.asarray(array_like()).view(dtype.base)
#a = numpy.asarray(array_like()).view(dtype.base)
#return a.tolist()
def pointers_to_ndarrays(addrs, dtypes, nitems):
print pointers_to_ndarrays() start, end
print addrs = , addrs
print dtypes = , dtypes
print nitems = , nitems
This is what we get:
local@ch400l-laptop:~$ /usr/local/share/grblock/examples/adder_demo.py
gateway_block.__init__() start
gateway_handler.__init__() start
gateway_handler.__init__() end
gateway_block.__init__() end
gateway_handler.handle() start
gateway_block.__grblock_handle() start
gateway_block.__grblock_handle() end
gateway_handler.handle() end
gateway_handler.handle() start
gateway_block.__grblock_handle() start
pointers_to_ndarrays() start, end
addrs = grblock.grblock_swig.size_t_vector_t; proxy of Swig Object of
type 'std::vector size_t *' at 0x235a720
dtypes = [dtype('float32'), dtype('float32')]
nitems = [5, 5]
handler caught exception: Unknown exception
Traceback (most recent call last):
File /usr/local/lib/python2.6/dist-packages/grblock/gateway.py, line
65,
in handle
try: self._callback()
File /usr/local/lib/python2.6/dist-packages/grblock/gateway.py, line
137,
in __grblock_handle
[self.__message.work_args.ninput_items]*len(self.__in_sig),
File /usr/local/lib/python2.6/dist-packages/grblock/gateway.py, line
51,
in pointers_to_ndarrays
return [pointer_to_ndarray(*args) for args in zip(addrs, dtypes,
nitems)]
File
/usr/local/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_core_hier.py,
line 118, in next
return _gnuradio_core_hier.SwigPyIterator_next(self)
RuntimeError: Unknown exception
gateway_handler.handle() start
gateway_block.__grblock_handle() start
gateway_block.__grblock_handle() end
gateway_handler.handle() end
thread[thread-per-block[2]: gr_block add 2 f32 (4)]: caught
unrecognized
exception
^Cexcepted (1, 5, 9, 13, 17)
actual ()
gateway_block.__init__() start
gateway_handler.__init__() start
gateway_handler.__init__() end
gateway_block.__init__() end
gateway_handler.handle() start
gateway_block.__grblock_handle() start
gateway_block.__grblock_handle() end
gateway_handler.handle() end
gateway_handler.handle() start
gateway_block.__grblock_handle() start
pointers_to_ndarrays() start, end
addrs = grblock.grblock_swig.size_t_vector_t; proxy of Swig Object of
type 'std::vector size_t *' at 0x235aa20
dtypes = [dtype('complex64'), dtype('complex64')]
nitems = [5, 5]
handler caught exception: Unknown exception
Traceback (most recent call last):
File /usr/local/lib/python2.6/dist-packages/grblock/gateway.py, line
65,
in handle
try: self._callback()
File /usr/local/lib/python2.6/dist-packages/grblock/gateway.py, line
137,
in __grblock_handle
[self.__message.work_args.ninput_items]*len(self.__in_sig),
File /usr/local/lib/python2.6/dist-packages/grblock/gateway.py, line
51,
in pointers_to_ndarrays
return [pointer_to_ndarray(*args) for args in zip(addrs, dtypes,
nitems)]
File
/usr/local/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_core_hier.py,
line 118, in next
return _gnuradio_core_hier.SwigPyIterator_next(self)
RuntimeError: Unknown exception
gateway_handler.handle() start
gateway_block.__grblock_handle() start
gateway_block.__grblock_handle() end
gateway_handler.handle() end
thread[thread-per-block[2]: gr_block add 2 fc32 (10)]: caught
unrecognized
exception
^Cexcepted (1, 5j, 9, 13j, 17)
actual ()
I have been on the digest subscription of gr discuss so I did not have
the
address to make sure I submit to the correct thread. I will on
[Discuss-gnuradio] Postdoctoral position open at the University of Utah
Dear Colleagues, The following postdoctoral position at the University of Utah is now open, and we are accepting applications. The Department of Electrical and Computer Engineering and the Sensing and Processing Across Networks (SPAN) Lab at the University of Utah (http://span.ece.utah.edu/) invites applications for an open postdoctoral fellow position for research in radio tomography, a research area at the intersection of statistical signal processing, radio wave propagation, and wireless networking. The SPAN lab, led by Prof. Neal Patwari, has significant expertise in radio channel signal processing for location estimation in wireless networks, including the 2008 ACM MobiCom Best Student Research Demo Award, a 2009 IEEE Signal Processing Magazine Best Paper Award, and significant popular press, including articles in MIT Technology Review, ScienceNOW, CNET, Engadget, Wired, Discover, Der Speigel, and The Economist. The SPAN lab is at the forefront of the area of device-free localization, having published six journal papers and three conference papers on the topic in the past three years. We have also developed methods to use wireless networks for breathing monitoring. This postdoctoral position would expand the state-of-the-art in the capability of wireless networks to learn about the positions and context of people in an environment, for both emergency situations, and for everyday applications. About the Position: The postdoctoral fellow position would start as soon as November, 2011, or as late as January, 2012, and would last from one to two years, based on research performance. The candidate must have a strong publication record including a history of presenting / publishing in the top conferences and journals. We are looking for a candidate with: - A Ph.D. in Electrical Engineering or Computer Science. - A strong background in statistical signal processing and/or wireless networking. Other skills that would benefit a candidate include: experimental experience, understanding of radio wave propagation, and leadership or mentoring experience. About the University of Utah: The University of Utah is located in Salt Lake City, Utah, which is unique for the outdoor activities available within a short drive of a major city. There are seven ski resorts within a 45 minute drive, six US national parks within the state borders, and many other public lands, including national forests accessible within minutes of Salt Lake. The University of Utah is well known for its research and entrepreneurial success. The U. of Utah is ranked 1st in the nation for creating new startup companies from research-based inventions, by the Association of University Technology Managers. More than 100 local companies have been founded by engineering graduates and faculty. In the last fiscal year, the University of Utah received $451 million in federal research funding, twice what it was six years ago. The University is particularly known for sensor network research, and has put significant resources into an cross-disciplinary group of faculty and facilities. To Apply: Application materials include (1) CV, (2) Link to homepage where most significant publications are available, and (3) contact information for three references. Send materials via email to Prof. Neal Patwari, npatwari at ece dot utah dot edu, with the subject, Postdoc Application. Regards, Prof. Neal Patwari University of Utah Department of Electrical and Computer Engineering Director, Sensing and Processing Across Networks (SPAN) Lab http://span.ece.utah.edu/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Error running benchmark_tx.py from next branch
Perhaps this is the wrong place to post this error, but I'm hoping for a quick response :) I'm getting a network unreachable error on an E100 when trying to run benchmark_tx.py from the gnuradio next branch (Tom Rondeau?). Command line error, and output of uhd_usrp_probe are attached. Thanks! Sean root@usrp-e1xx:/usr/local/share/gnuradio/examples/digital# ./benchmark_tx.py -f 9 --tx-amplitude=0.36 -v --tx-gain=0.0 -r 4 -m bpsk linux; GNU C++ version 4.5.3 20110311 (prerelease); Boost_104500; UHD_003.003.000-e0a7b8a Traceback (most recent call last): File ./benchmark_tx.py, line 148, in module main() File ./benchmark_tx.py, line 112, in main tb = my_top_block(mods[options.modulation], options) File ./benchmark_tx.py, line 49, in __init__ options.antenna, options.verbose) File /usr/local/share/gnuradio/examples/digital/uhd_interface.py, line 135, in __init__ freq, gain, antenna) File /usr/local/share/gnuradio/examples/digital/uhd_interface.py, line 51, in __init__ num_channels=1) File /usr/local/lib/python2.6/site-packages/gnuradio/uhd/__init__.py, line 84, in constructor_interceptor return old_constructor(*args, **kwargs) File /usr/local/lib/python2.6/site-packages/gnuradio/uhd/uhd_swig.py, line 2003, in usrp_sink return _uhd_swig.usrp_sink(*args, **kwargs) RuntimeError: Network is unreachable linux; GNU C++ version 4.5.3 20110311 (prerelease); Boost_104500; UHD_003.003.000-e0a7b8a -- Opening device node /dev/usrp_e0... -- Initializing FPGA clock to 64.00MHz... -- USRP-E100 clock control: 6 -- r_counter: 1 -- a_counter: 0 -- b_counter: 12 -- prescaler: 8 -- vco_divider: 2 -- chan_divider: 15 -- vco_rate: 1920.00MHz -- chan_rate: 960.00MHz -- out_rate: 64.00MHz -- -- Performing wishbone readback test... pass -- Found a Jackson Labs GPS -- Setting references to the internal GPSDO -- Initializing time to the internal GPSDO _ / | Device: E-Series Device | _ |/ | | Mboard: E100 (euewanee) | | vendor: 3 | | device: 1 | | revision: 4 | | content: 0 | | model: E100 | | serial: E2R11Y3E1 | | | | Time sources: none, external, _external_ | | Clock sources: internal, external, auto | | Sensors: ref_locked, gps_gpgga, gps_gprmc, gps_gpgsa, gps_time, gps_locked | | _ | |/ | | | RX DSP: 0 | | | Freq range: -32.000 to 32.000 Mhz | | _ | |/ | | | RX DSP: 1 | | | Freq range: -32.000 to 32.000 Mhz | | _ | |/ | | | RX Dboard: A | | | ID: RFX900 (0x0025) | | | Serial: E0R11X1R9 | | | _ | | |/ | | | | RX Subdev: 0 | | | | Name: RFX900 (0x0025) | | | | Antennas: TX/RX, RX2 | | | | Sensors: lo_locked, rssi | | | | Freq range: 750.000 to 1050.000 Mhz | | | | Gain range PGA0: 0.0 to 70.0 step 0.0 dB | | | | Connection Type: QI | | | | Uses LO offset: No | | | _ | | |/ | | | | RX Codec: A | | | | Name: ad9522 | | | | Gain range pga: 0.0 to 20.0 step 1.0 dB | | _ | |/ | | | TX DSP: 0 | | | Freq range: -32.000 to 32.000 Mhz | | _ | |/ | | | TX Dboard: A | | | ID: RFX900 (0x0029) | | | Serial: E0R11X1R9 | | | _ | | |/ | | | | TX Subdev: 0 | | | | Name: RFX900 (0x0029) | | | | Antennas: TX/RX | | | | Sensors: lo_locked | | | | Freq range: 750.000 to 1050.000 Mhz | | | | Gain Elements: None | | | | Connection Type: IQ | | | | Uses LO offset: Yes | | | _ | | |/ | | | | TX Codec: A | | | | Name: ad9522 | | | | Gain range pga: -20.0 to 0.0 step 0.1 dB ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error running benchmark_tx.py from next branch
Perhaps this is the wrong place to post this error, but I'm hoping for a quick response J I'm getting a network unreachable error on an E100 when trying to run benchmark_tx.py from the gnuradio next branch (Tom Rondeau?). Command line error, and output of uhd_usrp_probe are attached. Thanks! Sean Probably needs a --args that tells UHD to go looking for the e100 interface, rather than whatever its default is. Perhaps Josh can comment on the search order that UHD uses when you don't explicitly specify a device, and is that order different on an e100? -- 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] Error running benchmark_tx.py from next branch
On Tue, Oct 18, 2011 at 4:02 PM, Nowlan, Sean sean.now...@gtri.gatech.eduwrote: I tried with the E100’s actual address and the loopback address (127.0.0.1) and both worked. I should also say it’s a bit confusing to call the command line switch “--address” when it’s actually handling the arguments the same way as uhd_find_devices, etc. handle the “--args” switch. For instance, I also got it to run with --address=”type=e100”. Also it’d be nice (but not necessary) to have the program automatically detect if it’s an E100 since it will never be controlling devices other than itself. ** ** Sean You're right about the address--args thing. I started doing all of this on a USRP N210, so it was always the systems IP address for me, so that's what it became. Now, to remember all of the places where I did it and correct for it... As for the auto-detection, I suppose it's possible to tap into the UHD's find_devices feature and just default to the first one it finds as opposed to a static default. I'll talk with Josh about doing this. Tom *From:* discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org[mailto: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] *On Behalf Of *Marcus D. Leech *Sent:* Tuesday, October 18, 2011 6:30 PM *To:* discuss-gnuradio@gnu.org *Subject:* Re: [Discuss-gnuradio] Error running benchmark_tx.py from next branch ** ** Perhaps this is the wrong place to post this error, but I’m hoping for a quick response J I’m getting a “network unreachable” error on an E100 when trying to run benchmark_tx.py from the gnuradio “next” branch (Tom Rondeau?). Command line error, and output of uhd_usrp_probe are attached. Thanks! Sean ** ** Probably needs a --args that tells UHD to go looking for the e100 interface, rather than whatever its default is. Perhaps Josh can comment on the search order that UHD uses when you don't explicitly specify a device, and is that order different on an e100? -- 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 mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error running benchmark_tx.py from next branch
On 10/18/2011 04:02 PM, Nowlan, Sean wrote: I tried with the E100's actual address and the loopback address (127.0.0.1) and both worked. I should also say it's a bit confusing to call the command line switch --address when it's actually handling the arguments the same way as uhd_find_devices, etc. handle the --args switch. For instance, I also got it to run with --address=type=e100. Also it'd be nice (but not necessary) to have the program automatically detect if it's an E100 since it will never be controlling devices other than itself. I think this will help clear some things up: http://files.ettus.com/uhd_docs/manual/html/identification.html#identifying-usrps So, e100 will not actually respond to the addr key. I believe that the error stems from the usrp2 find routine trying to send a discovery packet on the address that you specified, which may be invalid to do. So I guess my question is, what device address arguments are being passed into the uhd source/sink constructor? I recommend using an empty device address. But if you have other usrps attached to the e100 somehow, and you build uhd with support for those usrps, you may want to specify type=e100 as a way to filter the other devices. -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error running benchmark_tx.py from next branch
Also in benchmark_tx.py I noticed that calling -m qpsk and -m bpsk still default to their differential versions unless I explicitly use the --non-differential switch. Was this intended? I assumed that specifying *psk vs. d*psk would do the right thing. Thanks, Sean P.S. - Thank you for your hard work moving the gnuradio examples to UHD! From: Tom Rondeau [mailto:trondeau1...@gmail.com] Sent: Tuesday, October 18, 2011 7:06 PM To: Nowlan, Sean Cc: Marcus D. Leech; discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Error running benchmark_tx.py from next branch On Tue, Oct 18, 2011 at 4:02 PM, Nowlan, Sean sean.now...@gtri.gatech.edumailto:sean.now...@gtri.gatech.edu wrote: I tried with the E100's actual address and the loopback address (127.0.0.1) and both worked. I should also say it's a bit confusing to call the command line switch --address when it's actually handling the arguments the same way as uhd_find_devices, etc. handle the --args switch. For instance, I also got it to run with --address=type=e100. Also it'd be nice (but not necessary) to have the program automatically detect if it's an E100 since it will never be controlling devices other than itself. Sean You're right about the address--args thing. I started doing all of this on a USRP N210, so it was always the systems IP address for me, so that's what it became. Now, to remember all of the places where I did it and correct for it... As for the auto-detection, I suppose it's possible to tap into the UHD's find_devices feature and just default to the first one it finds as opposed to a static default. I'll talk with Josh about doing this. Tom From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.orgmailto:gtri.gatech@gnu.org [mailto:discuss-gnuradio-bounces+sean.nowlanmailto:discuss-gnuradio-bounces%2Bsean.nowlan=gtri.gatech@gnu.orgmailto:gtri.gatech@gnu.org] On Behalf Of Marcus D. Leech Sent: Tuesday, October 18, 2011 6:30 PM To: discuss-gnuradio@gnu.orgmailto:discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Error running benchmark_tx.py from next branch Perhaps this is the wrong place to post this error, but I'm hoping for a quick response :) I'm getting a network unreachable error on an E100 when trying to run benchmark_tx.py from the gnuradio next branch (Tom Rondeau?). Command line error, and output of uhd_usrp_probe are attached. Thanks! Sean Probably needs a --args that tells UHD to go looking for the e100 interface, rather than whatever its default is. Perhaps Josh can comment on the search order that UHD uses when you don't explicitly specify a device, and is that order different on an e100? -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.orgmailto: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] Error running benchmark_tx.py from next branch
On Tue, Oct 18, 2011 at 4:18 PM, Nowlan, Sean sean.now...@gtri.gatech.eduwrote: Also in benchmark_tx.py I noticed that calling “-m qpsk” and “-m bpsk” still default to their differential versions unless I explicitly use the “--non-differential” switch. Was this intended? I assumed that specifying “*psk” vs. “d*psk” would do the right thing. No intentional, and I thought I had it working correctly. It's an issue with the OptionParser and having two options with the same name. They step on each other. I need to figure out a better way to handle that. Thanks, Sean ** ** P.S. – Thank you for your hard work moving the gnuradio examples to UHD! You're welcome! Tom *From:* Tom Rondeau [mailto:trondeau1...@gmail.com] *Sent:* Tuesday, October 18, 2011 7:06 PM *To:* Nowlan, Sean *Cc:* Marcus D. Leech; discuss-gnuradio@gnu.org *Subject:* Re: [Discuss-gnuradio] Error running benchmark_tx.py from next branch ** ** On Tue, Oct 18, 2011 at 4:02 PM, Nowlan, Sean sean.now...@gtri.gatech.edu wrote: I tried with the E100’s actual address and the loopback address (127.0.0.1) and both worked. I should also say it’s a bit confusing to call the command line switch “--address” when it’s actually handling the arguments the same way as uhd_find_devices, etc. handle the “--args” switch. For instance, I also got it to run with --address=”type=e100”. Also it’d be nice (but not necessary) to have the program automatically detect if it’s an E100 since it will never be controlling devices other than itself. Sean ** ** You're right about the address--args thing. I started doing all of this on a USRP N210, so it was always the systems IP address for me, so that's what it became. Now, to remember all of the places where I did it and correct for it... ** ** As for the auto-detection, I suppose it's possible to tap into the UHD's find_devices feature and just default to the first one it finds as opposed to a static default. I'll talk with Josh about doing this. ** ** Tom ** ** *From:* discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org[mailto: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] *On Behalf Of *Marcus D. Leech *Sent:* Tuesday, October 18, 2011 6:30 PM *To:* discuss-gnuradio@gnu.org *Subject:* Re: [Discuss-gnuradio] Error running benchmark_tx.py from next branch Perhaps this is the wrong place to post this error, but I’m hoping for a quick response J I’m getting a “network unreachable” error on an E100 when trying to run benchmark_tx.py from the gnuradio “next” branch (Tom Rondeau?). Command line error, and output of uhd_usrp_probe are attached. Thanks! Sean Probably needs a --args that tells UHD to go looking for the e100 interface, rather than whatever its default is. Perhaps Josh can comment on the search order that UHD uses when you don't explicitly specify a device, and is that order different on an e100? -- 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 mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error running benchmark_tx.py from next branch
On Tue, Oct 18, 2011 at 4:19 PM, Josh Blum j...@ettus.com wrote: On 10/18/2011 04:02 PM, Nowlan, Sean wrote: I tried with the E100's actual address and the loopback address (127.0.0.1) and both worked. I should also say it's a bit confusing to call the command line switch --address when it's actually handling the arguments the same way as uhd_find_devices, etc. handle the --args switch. For instance, I also got it to run with --address=type=e100. Also it'd be nice (but not necessary) to have the program automatically detect if it's an E100 since it will never be controlling devices other than itself. I think this will help clear some things up: http://files.ettus.com/uhd_docs/manual/html/identification.html#identifying-usrps So, e100 will not actually respond to the addr key. I believe that the error stems from the usrp2 find routine trying to send a discovery packet on the address that you specified, which may be invalid to do. So I guess my question is, what device address arguments are being passed into the uhd source/sink constructor? I recommend using an empty device address. But if you have other usrps attached to the e100 somehow, and you build uhd with support for those usrps, you may want to specify type=e100 as a way to filter the other devices. -Josh So does an empty string default to the first UHD device found? If so, then that solves the problem, and I'll change all of the defaults to that (along with the change to args). Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error running benchmark_tx.py from next branch
On 10/18/2011 04:23 PM, Tom Rondeau wrote: On Tue, Oct 18, 2011 at 4:19 PM, Josh Blum j...@ettus.com wrote: On 10/18/2011 04:02 PM, Nowlan, Sean wrote: I tried with the E100's actual address and the loopback address (127.0.0.1) and both worked. I should also say it's a bit confusing to call the command line switch --address when it's actually handling the arguments the same way as uhd_find_devices, etc. handle the --args switch. For instance, I also got it to run with --address=type=e100. Also it'd be nice (but not necessary) to have the program automatically detect if it's an E100 since it will never be controlling devices other than itself. I think this will help clear some things up: http://files.ettus.com/uhd_docs/manual/html/identification.html#identifying-usrps So, e100 will not actually respond to the addr key. I believe that the error stems from the usrp2 find routine trying to send a discovery packet on the address that you specified, which may be invalid to do. So I guess my question is, what device address arguments are being passed into the uhd source/sink constructor? I recommend using an empty device address. But if you have other usrps attached to the e100 somehow, and you build uhd with support for those usrps, you may want to specify type=e100 as a way to filter the other devices. -Josh So does an empty string default to the first UHD device found? If so, then that solves the problem, and I'll change all of the defaults to that (along with the change to args). Yea, empty device address will find everything it can. And the first device found will be the one thats instantiated. -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Segmentation Fault
Hi all, I am facing Segmentation Fault error. My setup is - Ubuntu 11.04, USRP2 with WBX board, gnuradio. The scenario is - When I run uhd_fft.py, I get the following - (gdb) run /usr/local/bin/uhd_fft.py Starting program: /usr/bin/python /usr/local/bin/uhd_fft.py [Thread debugging using libthread_db enabled] linux; GNU C++ version 4.5.2; Boost_103700; UHD_003.003.000-25f0bd5 [New Thread 0x7fffe1adf700 (LWP 26034)] [New Thread 0x7fffe12de700 (LWP 26035)] usrp_source make Making -- Opening a USRP2/N-Series device... [New Thread 0x7fffe0add700 (LWP 26036)] UHD Warning: The recv buffer could not be resized sufficiently. Target sock buff size: 5000 bytes. Actual sock buff size: 131071 bytes. See the transport application notes on buffer resizing. Please run: sudo sysctl -w net.core.rmem_max=5000 UHD Warning: The recv buffer could not be resized sufficiently. Target sock buff size: 5000 bytes. Actual sock buff size: 131071 bytes. See the transport application notes on buffer resizing. Please run: sudo sysctl -w net.core.rmem_max=5000 UHD Warning: The send buffer could not be resized sufficiently. Target sock buff size: 1048576 bytes. Actual sock buff size: 131071 bytes. See the transport application notes on buffer resizing. Please run: sudo sysctl -w net.core.wmem_max=1048576 Program received signal SIGSEGV, *Segmentation fault*. [Switching to Thread 0x7fffe0add700 (LWP 26036)] 0x757d6973 in std::_Rb_tree_increment(std::_Rb_tree_node_base*) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (gdb) backtrace #0 0x757d6973 in std::_Rb_tree_increment(std::_Rb_tree_node_base*) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #1 0x7419bc68 in tls_destructor () from /usr/lib/libboost_thread.so.1.42.0 #2 0x7419e177 in thread_proxy () from /usr/lib/libboost_thread.so.1.42.0 #3 0x77bc4d8c in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #4 0x76a8a04d in clone () from /lib/x86_64-linux-gnu/libc.so.6 #5 0x in ?? () (gdb) * * The UHD logs file has been attached with the mail. Also, USRP1 with uhd_fft.py is working fine. USRP2 works fine if there is no UI involved (that is - /usr/local/share/uhd/examples/rx_ascii_art_dft --freq 900e6 --rate 1e6 --dyn-rng 120 works fine). Can some one please take a look at this problem? Thanks, Sriharsha Puranik. -- 2011-Oct-18 19:27:04.286141 - level 1 -- static void uhd::device::register_device(const uhd::device::find_t, const uh -- lib/device.cpp:69 registering device -- 2011-Oct-18 19:27:04.286302 - level 1 -- static void uhd::device::register_device(const uhd::device::find_t, const uh -- lib/device.cpp:69 registering device -- 2011-Oct-18 19:27:04.286346 - level 1 -- static void uhd::device::register_device(const uhd::device::find_t, const uh -- lib/device.cpp:69 registering device -- 2011-Oct-18 19:27:04.286481 - level 1 -- void register_dboard_key(const dboard_key_t, uhd::usrp::dboard_base::sptr (* -- lib/usrp/dboard_manager.cpp:94 registering: TVRX2 -- 2011-Oct-18 19:27:04.286532 - level 1 -- void register_dboard_key(const dboard_key_t, uhd::usrp::dboard_base::sptr (* -- lib/usrp/dboard_manager.cpp:94 registering: DBSRX2 -- 2011-Oct-18 19:27:04.286574 - level 1 -- void register_dboard_key(const dboard_key_t, uhd::usrp::dboard_base::sptr (* -- lib/usrp/dboard_manager.cpp:94 registering: TVRX -- 2011-Oct-18 19:27:04.286600 - level 1 -- void register_dboard_key(const dboard_key_t, uhd::usrp::dboard_base::sptr (* -- lib/usrp/dboard_manager.cpp:94 registering: Unknown TX -- 2011-Oct-18 19:27:04.286623 - level 1 -- void register_dboard_key(const dboard_key_t, uhd::usrp::dboard_base::sptr (* --
Re: [Discuss-gnuradio] fan replacement for usrp1?
ok so this has been working just fine at home, but i am actually beginning to use the usrp in performances fairly regularly, and you never know what might happen in such situations… so just to be on the safe side, i'd really rather replace the fan. unfortunately i'm not having much luck finding the exact fan that came with it in stock anywhere, but i've found a possible replacement that seems to basically meet the specs: http://search.digikey.com/us/en/products/F410T-05LC/563-1130-ND/1165524 the only thing that doesn't match up is the air flow— it's rated at 3.9CFM rather than the cooltron's 4.6CFM. anyone have a clue as to whether or not this would be enough of a difference to cause concern? otherwise the specs look fine, and it's supposed to have a noise floor of 12 dBA instead of ~21, so we're talking roughly half the volume… could really make a difference. thanks in advance, mark p.s. does anyone else have this same issue or is it just me? i'm wondering if maybe it's just that my fan is defective… 20 dBA should be a whisper and mine seems to be much louder than that. -- mark.cetilia.org | mem1.com | reduxproject.com On Oct 9, 2011, at 2:04 PM, Mark Cetilia wrote: ah yes, i feel it coming back, slowly. thank you :) m -- mark.cetilia.org | mem1.com | reduxproject.com On Oct 9, 2011, at 3:39 AM, Mike Jameson wrote: Hi Mark, If you take off the top of the enclosure on the USRP1 then you don't even need a fan! Your sanity should then return :) Mike M0MIK On 9 October 2011 06:43, Mark Cetilia m...@cetilia.org wrote: wondering if anybody out there has replaced their usrp1 fan with something a bit quieter? i find myself listening to its incessant whine many hours a day, and it's starting to make me a little crazy— especially when i am trying to listen to subtle details… anybody have a suggestion for a decent replacement? cheers, mark -- mark.cetilia.org | mem1.com | reduxproject.com ___ 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
Re: [Discuss-gnuradio] fan replacement for usrp1?
Yes I have. I disconnected it. In my opinion, it is overkill for anything going on in a USRP1. YMMV, Bob On Sun, Oct 9, 2011 at 1:43 AM, Mark Cetilia m...@cetilia.org wrote: wondering if anybody out there has replaced their usrp1 fan with something a bit quieter? i find myself listening to its incessant whine many hours a day, and it's starting to make me a little crazy— especially when i am trying to listen to subtle details… anybody have a suggestion for a decent replacement? cheers, mark -- mark.cetilia.org | mem1.com | reduxproject.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Bob McGwier Facebook: N4HYBob ARS: N4HY ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error running benchmark_tx.py from next branch
On Tue, Oct 18, 2011 at 4:40 PM, Nowlan, Sean sean.now...@gtri.gatech.eduwrote: One more thing – it looks like BITRATE refers to the USRP sample rate as opposed to the bitrate of the modulation scheme. I think this is a little confusing. Please correct me if I’m wrong with this math, using QPSK as an example: actual_bitrate = (2 bits/symbol) * 1/(SPS) * BITRATE,where SPS=(samples/symbol) and BITRATE is the USRP sample rate. ** ** Thanks, Sean I thought it was the bitrate; must have been another oversight when I was working on it. I'll fix that, too. Thanks for the bug reports (and useful suggestions)! Tom *From:* discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org[mailto: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] *On Behalf Of *Tom Rondeau *Sent:* Tuesday, October 18, 2011 7:24 PM *To:* j...@ettus.com *Cc:* discuss-gnuradio@gnu.org *Subject:* Re: [Discuss-gnuradio] Error running benchmark_tx.py from next branch ** ** On Tue, Oct 18, 2011 at 4:19 PM, Josh Blum j...@ettus.com wrote: On 10/18/2011 04:02 PM, Nowlan, Sean wrote: I tried with the E100's actual address and the loopback address (127.0.0.1) and both worked. I should also say it's a bit confusing to call the command line switch --address when it's actually handling the arguments the same way as uhd_find_devices, etc. handle the --args switch. For instance, I also got it to run with --address=type=e100. Also it'd be nice (but not necessary) to have the program automatically detect if it's an E100 since it will never be controlling devices other than itself. I think this will help clear some things up: http://files.ettus.com/uhd_docs/manual/html/identification.html#identifying-usrps So, e100 will not actually respond to the addr key. I believe that the error stems from the usrp2 find routine trying to send a discovery packet on the address that you specified, which may be invalid to do. So I guess my question is, what device address arguments are being passed into the uhd source/sink constructor? I recommend using an empty device address. But if you have other usrps attached to the e100 somehow, and you build uhd with support for those usrps, you may want to specify type=e100 as a way to filter the other devices. -Josh ** ** So does an empty string default to the first UHD device found? If so, then that solves the problem, and I'll change all of the defaults to that (along with the change to args). ** ** Tom ** ** ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Developers' Call, Oct. 20, 2011
We will be having our monthly Developers' conference call this Thursday, Oct. 20, 2011. Time: 10 PM UTC (6 PM EDT, 3 PM PDT) SIP: sip:gnura...@digitalbazaar.com IRC: #gnuradio on freenode Agenda: http://gnuradio.org/redmine/projects/gnuradio/wiki/Call20111020 Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] fan replacement for usrp1?
Ah good, glad to hear it's not just me… Do you run it with the top on or leave it open? Cheers, Mark -- mark.cetilia.org | mem1.com | reduxproject.com On Oct 18, 2011, at 11:02 PM, Robert McGwier wrote: Yes I have. I disconnected it. In my opinion, it is overkill for anything going on in a USRP1. YMMV, Bob On Sun, Oct 9, 2011 at 1:43 AM, Mark Cetilia m...@cetilia.org wrote: wondering if anybody out there has replaced their usrp1 fan with something a bit quieter? i find myself listening to its incessant whine many hours a day, and it's starting to make me a little crazy— especially when i am trying to listen to subtle details… anybody have a suggestion for a decent replacement? cheers, mark -- mark.cetilia.org | mem1.com | reduxproject.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Bob McGwier Facebook: N4HYBob ARS: N4HY ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
