[Discuss-gnuradio] gr-sounder in GNU Radio 3.5
Hello, I was just asking myself, why gr-sounder isn't contained in GNU Radio 3.5 any more. Does anybody know the reason? Thanks. Best regards, Daniel ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-sounder in GNU Radio 3.5
On Mon, Jan 30, 2012 at 02:00:03PM +0100, Daniel Bartel wrote: > Hello, > > I was just asking myself, why gr-sounder isn't contained in GNU Radio 3.5 any > more. > Does anybody know the reason? Hi Daniel, I wasn't involved in the decision, but gr-sounder didn't really do anything useful, it was more a proof-of-concept thing than anything else. Plus, it only worked with USRP1 and wasn't UHD compatible. Personally, I'm glad it's out of the core tree which should focus on other things. It's still there in the old branches, though. If you really want to try the code, you can copy it out of an older revision (anyone will do, gr-sounder wasn't changed in years). But beware, gr-sounder didn't have synchronization features and the results were not really useful. If you want to use it for real sounding, you will have to work on the FPGA image and probably the host code, too. Cheers MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgpgmkJCzTivR.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Running tunnel.py/benchmark_tx.py (OFDM) with XCVR2450?
On Mon, Jan 30, 2012 at 04:11:05PM +0100, Florian Schlembach wrote: > We have now extended our tests to the tests with two USRP2s with > daughterboards: Neither the benchmark_tx.py example nor the tunnel.py is > receiving any packets. We checked the spectrum and tuned the gains as well. > (OFDM) > > Now, we played with the benchmark files and tunnel.py located in the > narrowband > folder and therefore changed the modulation scheme from BPSK to GMSK and > ultimately receiving all the packets!! That's strange. > > Does anybody knows what code be the problem that we can't establish any > connection using higher order modulation schemes? Could it possibly be our > slightly outdated UHD version? > > We are totally clueless, so we appreciate any idea/help! This won't really help, but I remember we had exactly the same troubles here. This was before UHD was even released, so I doubt that's the reason. Unfortunately, I can't remember how (or: if) we fixed it :( but I'll keep you updated if my memory comes up with something. But fiddling with gain values is often useful; even if you've already done that I recommend trying again, by reducing tx-amplitude and the actual gain values, shifting the terminals around (perhaps they're too close?). MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgpx9MLweYYZj.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Quetion regarding crc checks .
Dear all, I am currently working on a gnuradio project and i was wondering if anybody could please share some information about how crc checks are made. As in when one makes a crc32 call from ones python script , in crc.py it says the following crc = digital_swig.crc32(s) and there after it makes a call to _digital_swig.crc32. I dont fully understand the "behind the scene operation" of "_digital_swig" . I understand that its a library associated file but its operation is what i cannot fully comprehend. Does it help make a call to digital_crc32.cc file which has all the underlying code. I would be awfully obliged if somebody were to spare sometime and help out in this regard. Thanks, Anay. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] reg overrun problem
Hi I was trying to run the benchmark_rx and benchmark_tx programs in the gnuradio 3.5.0 version, in my college lab. But I saw that when I am running the benchmark_rx in one of the wireless nodes, it shows the 'O'. there are core i7 processors in the nodes, and I am not sure why this overrun problem is occurring. Can anyone tell me why this error occurs and what I should do to overcome it? Thanks -- Regards Shantharam Balasubramanian MS in Electrical and Computer Engineering Rutgers University Ph:732-543-6863 Email:shantharam...@gmail.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] reg overrun problem
On 01/30/2012 09:41 AM, shantharam balasubramanian wrote: > Hi > > I was trying to run the benchmark_rx and benchmark_tx programs in the > gnuradio 3.5.0 version, in my college lab. But I saw that when I am running > the benchmark_rx in one of the wireless nodes, it shows the 'O'. > > there are core i7 processors in the nodes, and I am not sure why this > overrun problem is occurring. Can anyone tell me why this error occurs and > what I should do to overcome it? > > Ahh, le benchmark. Its more a proof of concept that you can implement a mac layer in gnuradio, and less so a benchmark of anything. :-) Here is a description of overflow: http://files.ettus.com/uhd_docs/manual/html/general.html#overflow-underflow-notes Faster processing can help, better code can help (if you care to optimize benchmark rx*), and if you have a network product, larger socket buffer can help: http://files.ettus.com/uhd_docs/manual/html/transport.html#resize-socket-buffers Not sure what modulation you selected, I think there may have been a weird issue with the FLL. Try the GMSK modulation option (which doesnt use the FLL), and see how well it works for you. If you are feeling adventurous, I have SIMD-optimized float adder/multiplier on my "next" branch. I think there are a few of these multiplier blocks in the path of benchmark rx. So I am curious to hear of the performance improvement of said math blocks provides any noticeable effect for you in the overall benchmark rx app. http://gnuradio.org/cgit/jblum.git/ Cheers, -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem finding gnuradio libraries on Mac OSX 10.6
I followed your advice, cleared everything out and started from scratch.
Installing to /usr/local from my home directory appears to work (both
dial_tone.py and my usrp B100) once I got my PYTHONPATH pointing in the
right direction.
For any total newbies out there (like me) running cmake with -LAH helped a
lot to get things pointed to the right libraries and directories.
Thanks again for the help.
On , Michael Dickens wrote:
Hi Scott - You shouldn't need to set the DYLD path. Have you verified
that the file "/opt/local/lib/libgnuradio-core.3.5.2git.dylib" exists?
Did you use /opt/local for the MacPorts install? I would -highly-
recommend keeping MacPorts and any local installs separate -- eg, use
/opt/local for MacPorts and /usr/local for anything installed by hand.
You shouldn't need to do "sudo make" to get everything to compile, no
matter if using CMake or GNU Autotools. All of this says to me that your
OS install is odd. - MLD
On Jan 29, 2012, at 9:53 PM, Scott Kovaleski wrote:
> Hello,
>
> I am very new to gnuradio, and I have been trying to build gnuradio on
Mac OSX 10.6.8 on a 2.4 GHz Intel Core Duo Macbook Pro. I tried the
Macports gnuradio, and it worked for me, but I couldn't get it to work
with UHD which (I think) I need for my B100 USRP.
>
> I installed the dependencies from Macports. I downloaded gnuradio from
git into /opt. I run cmake in /opt/gnuradio/build with the following
options:
>
> sudo cmake -LAH -DCMAKE_INSTALL_PREFIX=/opt/local \
> -DQWT_LIBRARIES=/opt/local/lib/libqwt.dylib \
> -DQWT_INCLUDE_DIRS=/opt/local/include/qwt \
> -DCMAKE_MAKE_PROGRAM=/usr/bin/make \
> -DPYTHON_EXECUTABLE=/opt/local/bin/python2.6 \
> -DPYTHON_LIBRARY=/opt/local/lib/libpython2.6.dylib \
>
-DPYTHON_INCLUDE_DIR=/opt/local/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6
\
> ../
>
> then sudo make, then sudo make test (all but one test passes). Not sure
if it's important, but I must use sudo even for cmake and make
>
> When I try to run dial_tone, however, I get the following:
>
> /opt/local/share/gnuradio/examples/audio> ./dial_tone.py
> Traceback (most recent call last):
> File "./dial_tone.py", line 24, in
> from gnuradio import gr
> File "/opt/local/lib/python2.6/site-packages/gnuradio/gr/__init__.py",
line 43, in
> from gnuradio_core import *
>
File "/opt/local/lib/python2.6/site-packages/gnuradio/gr/gnuradio_core.py",
line 23, in
> from gnuradio_core_runtime import *
>
File "/opt/local/lib/python2.6/site-packages/gnuradio/gr/gnuradio_core_runtime.py",
line 26, in
> _gnuradio_core_runtime = swig_import_helper()
>
File "/opt/local/lib/python2.6/site-packages/gnuradio/gr/gnuradio_core_runtime.py",
line 22, in swig_import_helper
> _mod = imp.load_module('_gnuradio_core_runtime', fp, pathname,
description)
> ImportError:
dlopen(/opt/local/lib/python2.6/site-packages/gnuradio/gr/_gnuradio_core_runtime.so,
2): Library not loaded: libgnuradio-core.3.5.2git.dylib
> Referenced from:
/opt/local/lib/python2.6/site-packages/gnuradio/gr/_gnuradio_core_runtime.so
> Reason: image not found
>
> When I run gnuradio-companion, I get an error window that says I should
check PYTHONPATH and LD_LIBRARY_PATH which are set in my .profile to be
the following:
>
> export
PYTHONPATH=/opt/local/lib/python2.6/site-packages:/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/:$PYTHONPATH
>
> export LD_LIBRARY_PATH=/opt/local/lib:$LD_LIBRARY_PATH
>
> I am at a loss at this point, and I would be grateful for any help.
>
> Regards,
>
> Scott
> ___
> 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] Restore USRP2 images to support old USRP2 (Not UHD) code
Hi All, I have burned the USRP2 to support the UHD, but now I need to run some old USRP2 code. The new burned USRP2 images don't support the old code. So, is there any ways I can restore USRP2 images to old version to support the old code? Any help is appreciated, thanks in advance. -- Wenbo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error while running std examples max_power.py, bert : boost::math::round(d): Value -nan
On Mon, Jan 16, 2012 at 10:13 AM, Tom Rondeau wrote:
> On Sun, Jan 15, 2012 at 11:32 PM, Tom Rondeau wrote:
>
>> On Fri, Jan 6, 2012 at 12:47 AM, Shalabh Jain wrote:
>>
>>> Hello,
>>>
>>> I recently installed the latest git pull of both the GNU Radio and UHD
>>> driver. I am getting the some relating to USRP initialization errors when
>>> I'm running some of the examples provided. max_power.py
>>> and digital_bert_tx.py or rx.py.
>>> My setup seems correct since I can run the fft scripts etc.
>>>
>>> It seems to be some kind of overflow that is causing this but I am not
>>> able to figure out why. I tried to use my limited debugging skills and have
>>> these comments
>>>
>>> 1. Since bert is similar to the benchmark_tx, on comparing the two, I
>>> see that in digital_bert_tx, the error goes away if you comment out
>>> self._modulator = self._modulator_class(**mod_kwargs)
>>> and pass
>>> self._modulator_class(**mod_kwargs)._constellation
>>> to the bert transmitter chain initialization.
>>>
>>> 2. There is a minor mismatch in the arguments to the uhd_transmitter
>>> initialization, a subdevice is expected between options.tx_gain
>>> and options.antenna.
>>> But that is certainly not causing the error.
>>>
>>> 3. Looking at the C++ source code, the line of code that is actually
>>> throwing the exception is in the UHD tree (Line 152 in the
>>> uhd_src/host/lib/device.cpp)
>>> device::sptr dev = maker(dev_addr);
>>>
>>
>> I'll look into this tomorrow. When we moved everything to gr-digital and
>> all of the examples to using UHD, we were moving quickly, and this might
>> have been left behind after some change. I know it was working when I first
>> added it. It looks like you found the fix; I'll verify it tomorrow.
>>
>>
>>
>>> 4. I cannot figure out any temporary fix for the max_power.py failure.
>>>
>>
>> I was debating over whether or not to even include this example when we
>> moved to using the UHD. This was a program only designed for the first gen
>> USRPs and libusrp. It's really probably not applicable to the conditions
>> under the UHD anymore, anyway. Again, I'll check it tomorrow.
>>
>>
>>> Has anybody else faced similar issues before or have any suggestions for
>>> debugging directions?
>>>
>>> Thanks
>>> Shalabh
>>>
>>
>>
>> Thanks for the feedback!
>>
>> Tom
>>
>>
>>
>>> Traceback (most recent call last): - From bert
>>> File "./digital_bert_tx.py", line 130, in
>>> tb = tx_psk_block(mod, options)
>>> File "./digital_bert_tx.py", line 73, in __init__
>>> options.antenna, options.verbose)
>>> File
>>> "/home/gnuradio/Shared/sj/usrp_stuff/code/s_eg/digital/narrowband/uhd_interface.py",
>>> line 137, in __init__
>>> freq, gain, spec, antenna)
>>> File
>>> "/home/gnuradio/Shared/sj/usrp_stuff/code/s_eg/digital/narrowband/uhd_interface.py",
>>> line 49, in __init__
>>> self.u = uhd.usrp_sink(device_addr=args,
>>> stream_args=uhd.stream_args('fc32'))
>>> File
>>> "/opt/gnuradio-3.5/lib/python2.6/dist-packages/gnuradio/uhd/__init__.py",
>>> line 112, in constructor_interceptor
>>> return old_constructor(*args)
>>> File
>>> "/opt/gnuradio-3.5/lib/python2.6/dist-packages/gnuradio/uhd/uhd_swig.py",
>>> line 2320, in usrp_sink
>>> return _uhd_swig.usrp_sink(*args)
>>> RuntimeError: Error in function boost::math::round(d): Value -nan can
>>> not be represented in the target integer type.
>>>
>>>
>>>
>>> Traceback (most recent call last): - From max_power.py
>>> File "./max_power.py", line 140, in
>>> main ()
>>> File "./max_power.py", line 133, in main
>>> tb = build_block (options.args, options.tx_enable, options.rx_enable)
>>> File "./max_power.py", line 63, in __init__
>>> self.u_tx = uhd.usrp_sink(device_addr=args, stream_args=stream_args)
>>> File
>>> "/opt/gnuradio-3.5/lib/python2.6/dist-packages/gnuradio/uhd/__init__.py",
>>> line 112, in constructor_interceptor
>>> return old_constructor(*args)
>>> File
>>> "/opt/gnuradio-3.5/lib/python2.6/dist-packages/gnuradio/uhd/uhd_swig.py",
>>> line 2320, in usrp_sink
>>> return _uhd_swig.usrp_sink(*args)
>>> RuntimeError: Error in function boost::math::round(d): Value -nan can
>>> not be represented in the target integer type.
>>>
>>
>
> Shalabh,
>
> I just pushed fixes to the digital BER tests. It was indeed a case that
> some things changed with how the UHD interface was used that did not get
> updated here. I just tested these over the air successfully.
>
> I was able to run the max_power.py script just fine. Can you post your
> hardware configuration so I can see if there is something specific there
> that's causing a problem?
>
> Thanks,
> Tom
>
>
Hi Tom,
The max_power.py script runs just fine. However, the problem still seems to
persists in general with other examples. I'm posting the error while
running digital_bert_tx.py below. It exists for the rx example as well. In
fact, with the latest version of gnuradio and uhd, even the uhd_fft.py as
stopped working. This was working prev
Re: [Discuss-gnuradio] Error while running std examples max_power.py, bert : boost::math::round(d): Value -nan
On 30/01/12 09:36 PM, Shalabh Jain wrote: > > Hi Tom, > > The max_power.py script runs just fine. However, the problem still > seems to persists in general with other examples. I'm posting the > error while running digital_bert_tx.py below. It exists for the rx > example as well. In fact, with the latest version of gnuradio and uhd, > even the uhd_fft.py as stopped working. This was working previously > and would occasionally error out. Posting the error message below. It > seems the problem is rooted deeper than the top level modules. > > My hardware is USRP2 (rev 4.0) with the XCVR2450 daughterboard. The > host machine is a Dell Optiplex 980. > Software versions are GNURadio (29aa72d4 - downloaded 1/30), UHD > (e30cf4ec - downloaded 1/30), Firmware (003.004.000-322fb97), Ubuntu > (10.04 - 32bit) > > If you need any more information, please let me know. I will try to > debug this further. Please let me know if you have any suggestions in > that direction. > > I'm really sorry for the delayed response. As I mentioned, I got > absorbed into some other work. > > Thanks for your help. > > Shalabh > In the case of uhd_fft.py, what parameters are you passing on the command line? -- 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] Field test on Nokia 8890
Hello, all... In trying to enable netmonitor on nokia 8890 with irda, but nothing happen. Gnokii config: [global] port = /dev/ircomm0 model = AT connection = irda [logging] debug = on when i try to enable: root@ruyi-Satellite-L645D:~/.config/gnokii# gnokii --netmonitor field GNOKII Version 0.6.30 LOG: debug mask is 0x1 Config read from file /home/ruyi/.config/gnokii/config. phone instance config: model = AT port = /dev/ircomm0 connection = irda initlength = default serial_baudrate = 19200 serial_write_usleep = -1 handshake = software require_dcd = 0 smsc_timeout = 10 rfcomm_channel = 0 sm_retry = 0 Initializing AT capable mobile phone ... Serial device: opening device /dev/ircomm0 Expecting: Default: Nokia 8890 a71d Message sent: 0x00 / 0x0004 41 54 5a 0d | ATZ write: [ATZ] Message sent: 0x00 / 0x0005 41 54 45 31 0d | ATE1 write: [ATE1] Message sent: 0x00 / 0x000a 41 54 2b 43 4d 45 45 3d 31 0d | AT+CMEE=1 write: [AT+CMEE=1] But nothing happen in the phone, i dont see the netmonitor menu.. Can anybody help me? Thank in advance Regards Cristian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error while running std examples max_power.py, bert : boost::math::round(d): Value -nan
On Mon, Jan 30, 2012 at 9:54 PM, Marcus D. Leech wrote: > On 30/01/12 09:36 PM, Shalabh Jain wrote: > > > > Hi Tom, > > > > The max_power.py script runs just fine. However, the problem still > > seems to persists in general with other examples. I'm posting the > > error while running digital_bert_tx.py below. It exists for the rx > > example as well. In fact, with the latest version of gnuradio and uhd, > > even the uhd_fft.py as stopped working. This was working previously > > and would occasionally error out. Posting the error message below. It > > seems the problem is rooted deeper than the top level modules. > > > > My hardware is USRP2 (rev 4.0) with the XCVR2450 daughterboard. The > > host machine is a Dell Optiplex 980. > > Software versions are GNURadio (29aa72d4 - downloaded 1/30), UHD > > (e30cf4ec - downloaded 1/30), Firmware (003.004.000-322fb97), Ubuntu > > (10.04 - 32bit) > > > > If you need any more information, please let me know. I will try to > > debug this further. Please let me know if you have any suggestions in > > that direction. > > > > I'm really sorry for the delayed response. As I mentioned, I got > > absorbed into some other work. > > > > Thanks for your help. > > > > Shalabh > > > In the case of uhd_fft.py, what parameters are you passing on the > command line? > > Just the frequency option (-f 2440M). -Shalabh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
