Re: [Discuss-gnuradio] INFO: Detected an invalid packet at item INFO: Parser returned #f
Hi,
On 01/29/2015 03:13 PM, zs wrote:
Can you tell me,for general,in which circumstance,the packet header maybe
corrupt?
This is very hard to tell since I don't know what you are doing. I guess
you use a header_formatter in your flow graph and (for whatever reason)
its header_parse method returns false.
For example with the default header it looks like this happens if the
CRC is not correct
https://github.com/gnuradio/gnuradio/blob/master/gr-digital/lib/packet_header_default.cc#L132
At 2015-01-29 20:44:13, Bastian Bloessl bloe...@ccs-labs.org wrote:
Hi,
On 01/29/2015 01:03 PM, zs wrote:
Detected an invalid packet at item INFO: Parser returned #f.
The answer may be RF settings are distorting your signal or others.I
want to ask a question.Which block in gnuradio give us this hint.Where
is the source code of the block?And have someone can help me to explain
this problem more details?Why will have this error/warning?
~/src/gnuradio ack-grep -C 3 an invalid packet
gr-digital/lib/packet_headerparser_b_impl.cc
80- );
81-
82- if (!d_header_formatter-header_parser(in, tags)) {
83: GR_LOG_INFO(d_logger, boost::format(Detected an invalid packet at
item %1%) % nitems_read(0));
84- message_port_pub(msg_port_id, pmt::PMT_F);
85- } else {
86- pmt::pmt_t dict(pmt::make_dict());
I guess your packet header is corrupt.
Best,
Bastian
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP B200 host BW with USB 3.0/2.0
Martin, The alternative of a USB 3.0 is not having 5 USRPs. It is just reading 5 times at different centrer frequencies in order to get 40MHz information although that information will not be gathered at the same time. For my application I just need to see the sprectrum. I do not need to demodulate data so that it would be fine to proceed that way. However i would rather get 40MHz in a row. Many thanks, Jorge On 29 January 2015 at 14:07, Martin Braun martin.br...@ettus.com wrote: On 01/29/2015 01:48 PM, Jorge Gallo wrote: I understand the given values of host bandwidth for each protocol: USB 2.0 8 (MS/s @ 16-bit I/Q) If you go down to 8-bit IQ, you will get twice that amount, if that's any help. USB 3.061.44 (MS/s @ 16-bit I/Q) However I would like to process 40MHz of analogue BW in GNURadio over USB 2.0 I fully understand a continuous reception is not possible to manage since it would require 40 IQ MS/s and I am limited to 8MS/s. However, is it possible to take snapshots of 40MHz over the time so that I am able to receive bits of 40MHz with USB 2.0 which are not continuous in time? Are there buffers in the FPGA that manage this kind of operation? None big enough for anything useful. It seems like attaching a USB3.0 connector would be simpler than running 5 USRPs? Not that I would complain about the sales :) M ___ 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] Issue with Results from GR-CDMA
Hello sorry for the last message thought i attached my screenshot results at first. I am having some problems as to whether the information from the cdma transmission and reception are accurate. I have posted my screenshots for clarification hopefully.http://imageshack.com/a/img633/757/Yx8B7r.png The first screenshot is from executing the cdma_txrx.grc which seems to test well I believe because moving the sliders around and threshold I am able to notice when it performs tracking and acquisition of the signal automatically. http://imageshack.com/a/img631/8451/CDqdTM.png The second screenshot is me loading two USRP's. This is the execution of the cdma_tx.grc file with the UHD:USRP Sink and its WX GUI FFT Plot. My issue here is the FFT plot doesn't look right to. By the way the channel model for this is AWGN. http://imageshack.com/a/img538/7792/1xXqN4.pngAfter running the cdma_tx.grc file, I proceed to go to my other laptop and run the cdma_rx.grc file which is connected to that USRP(UHD USRP SOURCE. The image above is what I get. In the beginning it seems to be acquiring the packets then a few seconds later a lot of invalid packets get detected. Overall all are these images close to what I should be seeing. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Asking help about gr-ieee802-11
Either python3 is selected by cmake or (maybe) your swig version does not work.
The first problem should have been fixed with the most recent commit (3 days
ago).
On 29 Jan 2015, at 09:15, Activecat active...@gmail.com wrote:
Dear Sir,
Thank you very much for your prompt response.
I really appreciate your help.
Refer below result:
sgku@mmu2: ~ $ ipython
Python 2.7.3 (default, Mar 14 2014, 11:57:14)
Type copyright, credits or license for more information.
IPython 0.13.1 -- An enhanced Interactive Python.
? - Introduction and overview of IPython's features.
%quickref - Quick reference.
help - Python's own help system.
object? - Details about 'object', use 'object??' for extra details.
In [1]: import ieee802_11
---
ImportError Traceback (most recent call last)
ipython-input-1-3c375f221e3a in module()
1 import ieee802_11
/usr/local/lib/python2.7/dist-packages/ieee802_11/__init__.py in module()
35
36 # import swig generated symbols into the test namespace
--- 37 from ieee802_11_swig import *
38
39 # import any pure python here
/usr/local/lib/python2.7/dist-packages/ieee802_11/ieee802_11_swig.py in
module()
24 fp.close()
25 return _mod
--- 26 _ieee802_11_swig = swig_import_helper()
27 del swig_import_helper
28 else:
/usr/local/lib/python2.7/dist-packages/ieee802_11/ieee802_11_swig.py in
swig_import_helper()
20 if fp is not None:
21 try:
--- 22 _mod = imp.load_module('_ieee802_11_swig', fp,
pathname, description)
23 finally:
24 fp.close()
ImportError: dynamic module does not define init function
(init_ieee802_11_swig)
On Thu, Jan 29, 2015 at 4:02 PM, Bastian Bloessl bloe...@ccs-labs.org wrote:
Hi,
On 29 Jan 2015, at 08:37, Activecat active...@gmail.com wrote:
error messages:
Param - Value(value):
Value ieee802_11.wifi_signal_field() cannot be evaluated:
name 'ieee802_11' is not defined
Please start an interactive python session and ‘import ieee802_11’. This will
give you more debug output. I guess either your $PYTHONPATH does not contain
the path of the module or some shared library can not be loaded.
Best,
Bastian
--
Dipl.-Inform. Bastian Bloessl
Distributed Embedded Systems Group
University of Paderborn, Germany
http://www.ccs-labs.org/~bloessl/
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] help
On Tue, Jan 27, 2015 at 3:26 AM, mery diana merydiana1...@gmail.com wrote: dear all members of milist i have tried to build aistx module using gr-moodtool, i got the source from github where using gnuradio 3.6 and i have modified to gnuradio 3.7 as instruction in http://gnuradio.org/redmine/projects/gnuradio/wiki/Move_3-6_to_3-7 but when i made a simulation in grc , i got error after running all,, Generating: /media/mdn-2014/6C4E8D6C4E8D303E/mery_diana/top_block.py Executing: /media/mdn-2014/6C4E8D6C4E8D303E/mery_diana/top_block.py linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.008.000-37-g7866b665 Traceback (most recent call last): File /media/mdn-2014/6C4E8D6C4E8D303E/mery_diana/top_block.py, line 19, in module import AISTX ImportError: No module named AISTX Done (return code 1) in gui of gnuradio-companion my module AISTX has installed and appered in the list of library,,, really need help, best regard. merydiana It's likely that you haven't set your PYTHONPATH or LD_LIBRARY_PATH correctly for the installed module. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Asking help about gr-ieee802-11
Hi, On 29 Jan 2015, at 08:37, Activecat active...@gmail.com wrote: error messages: Param - Value(value): Value ieee802_11.wifi_signal_field() cannot be evaluated: name 'ieee802_11' is not defined Please start an interactive python session and ‘import ieee802_11’. This will give you more debug output. I guess either your $PYTHONPATH does not contain the path of the module or some shared library can not be loaded. Best, Bastian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Asking help about gr-ieee802-11
Dear Sir,
Thank you very much for your prompt response.
I really appreciate your help.
Refer below result:
sgku@mmu2: ~ $ ipython
Python 2.7.3 (default, Mar 14 2014, 11:57:14)
Type copyright, credits or license for more information.
IPython 0.13.1 -- An enhanced Interactive Python.
? - Introduction and overview of IPython's features.
%quickref - Quick reference.
help - Python's own help system.
object? - Details about 'object', use 'object??' for extra details.
In [1]: import ieee802_11
---
ImportError Traceback (most recent call last)
ipython-input-1-3c375f221e3a in module()
1 import ieee802_11
/usr/local/lib/python2.7/dist-packages/ieee802_11/__init__.py in module()
35
36 # import swig generated symbols into the test namespace
--- 37 from ieee802_11_swig import *
38
39 # import any pure python here
/usr/local/lib/python2.7/dist-packages/ieee802_11/ieee802_11_swig.py in
module()
24 fp.close()
25 return _mod
--- 26 _ieee802_11_swig = swig_import_helper()
27 del swig_import_helper
28 else:
/usr/local/lib/python2.7/dist-packages/ieee802_11/ieee802_11_swig.py in
swig_import_helper()
20 if fp is not None:
21 try:
--- 22 _mod = imp.load_module('_ieee802_11_swig', fp,
pathname, description)
23 finally:
24 fp.close()
ImportError: dynamic module does not define init function
(init_ieee802_11_swig)
On Thu, Jan 29, 2015 at 4:02 PM, Bastian Bloessl bloe...@ccs-labs.org
wrote:
Hi,
On 29 Jan 2015, at 08:37, Activecat active...@gmail.com wrote:
error messages:
Param - Value(value):
Value ieee802_11.wifi_signal_field() cannot be evaluated:
name 'ieee802_11' is not defined
Please start an interactive python session and ‘import ieee802_11’. This
will give you more debug output. I guess either your $PYTHONPATH does not
contain the path of the module or some shared library can not be loaded.
Best,
Bastian
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Asking help about gr-ieee802-11
Dear Bastian,
Yes, this solves all the problems.
I just get the current commit and recompile, everything works !
Thank you very much.
On Thu, Jan 29, 2015 at 4:20 PM, Bastian Bloessl bloe...@ccs-labs.org
wrote:
Either python3 is selected by cmake or (maybe) your swig version does not
work. The first problem should have been fixed with the most recent commit
(3 days ago).
On 29 Jan 2015, at 09:15, Activecat active...@gmail.com wrote:
Dear Sir,
Thank you very much for your prompt response.
I really appreciate your help.
Refer below result:
sgku@mmu2: ~ $ ipython
Python 2.7.3 (default, Mar 14 2014, 11:57:14)
Type copyright, credits or license for more information.
IPython 0.13.1 -- An enhanced Interactive Python.
? - Introduction and overview of IPython's features.
%quickref - Quick reference.
help - Python's own help system.
object? - Details about 'object', use 'object??' for extra details.
In [1]: import ieee802_11
---
ImportError Traceback (most recent call
last)
ipython-input-1-3c375f221e3a in module()
1 import ieee802_11
/usr/local/lib/python2.7/dist-packages/ieee802_11/__init__.py in
module()
35
36 # import swig generated symbols into the test namespace
--- 37 from ieee802_11_swig import *
38
39 # import any pure python here
/usr/local/lib/python2.7/dist-packages/ieee802_11/ieee802_11_swig.py in
module()
24 fp.close()
25 return _mod
--- 26 _ieee802_11_swig = swig_import_helper()
27 del swig_import_helper
28 else:
/usr/local/lib/python2.7/dist-packages/ieee802_11/ieee802_11_swig.py in
swig_import_helper()
20 if fp is not None:
21 try:
--- 22 _mod = imp.load_module('_ieee802_11_swig', fp,
pathname, description)
23 finally:
24 fp.close()
ImportError: dynamic module does not define init function
(init_ieee802_11_swig)
On Thu, Jan 29, 2015 at 4:02 PM, Bastian Bloessl bloe...@ccs-labs.org
wrote:
Hi,
On 29 Jan 2015, at 08:37, Activecat active...@gmail.com wrote:
error messages:
Param - Value(value):
Value ieee802_11.wifi_signal_field() cannot be evaluated:
name 'ieee802_11' is not defined
Please start an interactive python session and ‘import ieee802_11’. This
will give you more debug output. I guess either your $PYTHONPATH does not
contain the path of the module or some shared library can not be loaded.
Best,
Bastian
--
Dipl.-Inform. Bastian Bloessl
Distributed Embedded Systems Group
University of Paderborn, Germany
http://www.ccs-labs.org/~bloessl/
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] QTGUI Issue
On Wed, Jan 28, 2015 at 2:06 PM, Richard Bell richard.be...@gmail.com wrote: If I attempt to manually configure the pyqt4 source that pybombs installed to pybombs/src/pyqt4, by executing the configure command I found in pyqt4's recipe file, the following errors occur: *[tsvcis@tsvtester pyqt4]$ python configure.py --confirm-license -b $prefix/bin -d $prefix/lib/python2.6/site-packages/ -v $prefix/share/sip/ --verboseDetermining the layout of your Qt installation.../usr/lib64/qt-3.3/bin/qmake -o qtdirs.mk http://qtdirs.mk qtdirs.pro http://qtdirs.pro* ^ I think there's a large part of the problem. It's trying to use a QT 3.3 installation instead of QT4. That's certainly not going to work. You likely don't need QT3 for anything anymore (I hope), so try getting rid of this and making sure there is only one version of QT4 installed. Also remember that pybombs has a '-v' flag you can pass to it to provide more version output. Tom *make -f qtdirs.mk http://qtdirs.mkg++ -c -pipe -Wall -W -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -fno-strict-aliasing -DQT_NO_DEBUG -DQT_SHARED -DQT_TABLET_SUPPORT -DQT_THREAD_SUPPORT -I/usr/lib64/qt-3.3/mkspecs/default -I. -I/usr/lib64/qt-3.3/include -o qtdirs.o qtdirs.cppqtdirs.cpp:1:17: error: QFile: No such file or directoryqtdirs.cpp:2:24: error: QLibraryInfo: No such file or directoryqtdirs.cpp:3:23: error: QTextStream: No such file or directoryqtdirs.cpp: In function ‘int main(int, char**)’:qtdirs.cpp:7: error: ‘QFile’ was not declared in this scopeqtdirs.cpp:7: error: expected ‘;’ before ‘outf’qtdirs.cpp:9: error: ‘outf’ was not declared in this scopeqtdirs.cpp:9: error: ‘QIODevice’ has not been declaredqtdirs.cpp:9: error: ‘QIODevice’ has not been declaredqtdirs.cpp:9: error: ‘QIODevice’ has not been declaredqtdirs.cpp:12: error: ‘QTextStream’ was not declared in this scopeqtdirs.cpp:12: error: expected ‘;’ before ‘out’qtdirs.cpp:14: error: ‘out’ was not declared in this scopeqtdirs.cpp:14: error: ‘QLibraryInfo’ has not been declaredqtdirs.cpp:14: error: ‘QLibraryInfo’ has not been declaredqtdirs.cpp:15: error: ‘QLibraryInfo’ has not been declaredqtdirs.cpp:15: error: ‘QLibraryInfo’ has not been declaredqtdirs.cpp:16: error: ‘QLibraryInfo’ has not been declaredqtdirs.cpp:16: error: ‘QLibraryInfo’ has not been declaredqtdirs.cpp:17: error: ‘QLibraryInfo’ has not been declaredqtdirs.cpp:17: error: ‘QLibraryInfo’ has not been declaredqtdirs.cpp:18: error: ‘QLibraryInfo’ has not been declaredqtdirs.cpp:18: error: ‘QLibraryInfo’ has not been declaredqtdirs.cpp:19: error: ‘QLibraryInfo’ has not been declaredqtdirs.cpp:19: error: ‘QLibraryInfo’ has not been declaredqtdirs.cpp:21: error: ‘QT_VERSION’ was not declared in this scopeqtdirs.cpp:22: error: ‘QT_EDITION’ was not declared in this scopeqtdirs.cpp:24: error: ‘QLibraryInfo’ has not been declaredqtdirs.cpp:90: error: ‘qreal’ was not declared in this scopemake: *** [qtdirs.o] Error 1Error: Failed to determine the layout of your Qt installation. Try again usingthe --verbose flag to see more detail about the problem.[tsvcis@tsvtester pyqt4]$* Keep in mind, this error is very different then the error pybombs reports during the automatic install. This leads me to believe my manual install may be leaving out configure information that is required by pyqt4 that pybombs normally handles. I'm just not sure. On Wed, Jan 28, 2015 at 10:30 AM, Richard Bell richard.be...@gmail.com wrote: I also realize I've been referring to PyQWT in previous emails as the problem, mistakingly. I meant to be saying PyQT4, as the previous thread output error shows. Apologies for the confusion. pyqt4 is the component which fails source installs on my fresh centos 6.6. Rich On Wed, Jan 28, 2015 at 8:42 AM, Richard Bell richard.be...@gmail.com wrote: You don't get much from this error. Copy and pasted below: *Installing from source: pyqt4Configuring: (100%) [==]Configuration failed. Re-trying with higher verbosity.make: *** No targets specified and no makefile found. Stop.Build failed. See output above for error messages.[tsvcis@tsvcistester pybombs]$ * I've recreated this error several times on clean CentOS 6.6 installs. Rich On Wed, Jan 28, 2015 at 1:07 AM, Tom Rondeau t...@trondeau.com wrote: On Tue, Jan 27, 2015 at 5:28 PM, Richard Bell richard.be...@gmail.com wrote: Yes I did ./pybombs remove, which uninstalls everything. I also have pybombs set to install everything from source, so I know for sure what's being installed. All but PyQWT, because that source install is broken for some reason. So the process is, I begin with ./pybombs install gnuradio This installs all dependencies for gnuradio until it gets to PyQWT and fails. I then install PyQWT through yum, because
Re: [Discuss-gnuradio] INFO: Detected an invalid packet at item INFO: Parser returned #f
Hi,
On 01/29/2015 01:03 PM, zs wrote:
Detected an invalid packet at item INFO: Parser returned #f.
The answer may be RF settings are distorting your signal or others.I
want to ask a question.Which block in gnuradio give us this hint.Where
is the source code of the block?And have someone can help me to explain
this problem more details?Why will have this error/warning?
~/src/gnuradio ack-grep -C 3 an invalid packet
gr-digital/lib/packet_headerparser_b_impl.cc
80- );
81-
82- if (!d_header_formatter-header_parser(in, tags)) {
83: GR_LOG_INFO(d_logger, boost::format(Detected an invalid packet at
item %1%) % nitems_read(0));
84- message_port_pub(msg_port_id, pmt::PMT_F);
85- } else {
86- pmt::pmt_t dict(pmt::make_dict());
I guess your packet header is corrupt.
Best,
Bastian
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP B200 host BW with USB 3.0/2.0
I made tests with the bladeRF at 30 MHz bandwidth, and I was able to see the spectrum just fine, not matter if I used a USB2 or a USB3 cable. No hacks, no switching chunks of the spectrum, just using a standard receiver program. The lost samples are not a problem as longs as you do not want to listen in. Ralph. From: discuss-gnuradio-bounces+ralph=schmid@gnu.org [mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of Jorge Gallo Sent: Thursday, January 29, 2015 4:07 PM To: Martin Braun Cc: GNURadio Discussion List Subject: Re: [Discuss-gnuradio] USRP B200 host BW with USB 3.0/2.0 Martin, The alternative of a USB 3.0 is not having 5 USRPs. It is just reading 5 times at different centrer frequencies in order to get 40MHz information although that information will not be gathered at the same time. For my application I just need to see the sprectrum. I do not need to demodulate data so that it would be fine to proceed that way. However i would rather get 40MHz in a row. Many thanks, Jorge On 29 January 2015 at 14:07, Martin Braun martin.br...@ettus.com mailto:martin.br...@ettus.com wrote: On 01/29/2015 01:48 PM, Jorge Gallo wrote: I understand the given values of host bandwidth for each protocol: USB 2.0 8 (MS/s @ 16-bit I/Q) If you go down to 8-bit IQ, you will get twice that amount, if that's any help. USB 3.061.44 (MS/s @ 16-bit I/Q) However I would like to process 40MHz of analogue BW in GNURadio over USB 2.0 I fully understand a continuous reception is not possible to manage since it would require 40 IQ MS/s and I am limited to 8MS/s. However, is it possible to take snapshots of 40MHz over the time so that I am able to receive bits of 40MHz with USB 2.0 which are not continuous in time? Are there buffers in the FPGA that manage this kind of operation? None big enough for anything useful. It seems like attaching a USB3.0 connector would be simpler than running 5 USRPs? Not that I would complain about the sales :) M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org mailto: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] USRP B200 host BW with USB 3.0/2.0
On 01/29/2015 01:48 PM, Jorge Gallo wrote: I understand the given values of host bandwidth for each protocol: USB 2.0 8 (MS/s @ 16-bit I/Q) If you go down to 8-bit IQ, you will get twice that amount, if that's any help. USB 3.061.44 (MS/s @ 16-bit I/Q) However I would like to process 40MHz of analogue BW in GNURadio over USB 2.0 I fully understand a continuous reception is not possible to manage since it would require 40 IQ MS/s and I am limited to 8MS/s. However, is it possible to take snapshots of 40MHz over the time so that I am able to receive bits of 40MHz with USB 2.0 which are not continuous in time? Are there buffers in the FPGA that manage this kind of operation? None big enough for anything useful. It seems like attaching a USB3.0 connector would be simpler than running 5 USRPs? Not that I would complain about the sales :) M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] INFO: Detected an invalid packet at item INFO: Parser returned #f
Hi all: Thank you in advance.I have searched the questionINFO: Detected an invalid packet at item INFO: Parser returned #f. The answer may be RF settings are distorting your signal or others.I want to ask a question.Which block in gnuradio give us this hint.Where is the source code of the block?And have someone can help me to explain this problem more details?Why will have this error/warning? Thank you. Best regards, zs ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP B200 host BW with USB 3.0/2.0
I understand the given values of host bandwidth for each protocol: USB 2.0 8 (MS/s @ 16-bit I/Q) USB 3.061.44 (MS/s @ 16-bit I/Q) However I would like to process 40MHz of analogue BW in GNURadio over USB 2.0 I fully understand a continuous reception is not possible to manage since it would require 40 IQ MS/s and I am limited to 8MS/s. However, is it possible to take snapshots of 40MHz over the time so that I am able to receive bits of 40MHz with USB 2.0 which are not continuous in time? Are there buffers in the FPGA that manage this kind of operation? The idea is to receive the high speed 40MHz in the FPGA and then send it over the USB 2.0. When it is accomplished we would be ready to receive another 40MHz sample block. I am afraid the only alternative is to receive 5 times 8MHz (each at 8Ms/s) so that I get 40MHz of analogue BW in 5 different readings/reconfigurations of my GNURadio flowgraph. However I ask just in case Many thanks in advance, Jorge. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP B200 host BW with USB 3.0/2.0
I understand his question that he just wants to let the whole thing pump out samples, and he takes only a portion of it. I have no idea if this works in a controlled manner, but at least for spectrum display this works just fine, the lost samples are not a big issue. Ralph. -Original Message- From: discuss-gnuradio-bounces+ralph=schmid@gnu.org [mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of Martin Braun Sent: Thursday, January 29, 2015 2:08 PM To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] USRP B200 host BW with USB 3.0/2.0 On 01/29/2015 01:48 PM, Jorge Gallo wrote: I understand the given values of host bandwidth for each protocol: USB 2.0 8 (MS/s @ 16-bit I/Q) If you go down to 8-bit IQ, you will get twice that amount, if that's any help. USB 3.061.44 (MS/s @ 16-bit I/Q) However I would like to process 40MHz of analogue BW in GNURadio over USB 2.0 I fully understand a continuous reception is not possible to manage since it would require 40 IQ MS/s and I am limited to 8MS/s. However, is it possible to take snapshots of 40MHz over the time so that I am able to receive bits of 40MHz with USB 2.0 which are not continuous in time? Are there buffers in the FPGA that manage this kind of operation? None big enough for anything useful. It seems like attaching a USB3.0 connector would be simpler than running 5 USRPs? Not that I would complain about the sales :) M ___ 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] INFO: Detected an invalid packet at item INFO: Parser returned #f
Hi Bastian:
Thank you so much for your kindly reply.Can you tell me,for
general,in which circumstance,the packet header maybe corrupt?
Thank you so much.
Best regards,
zs
At 2015-01-29 20:44:13, Bastian Bloessl bloe...@ccs-labs.org wrote:
Hi,
On 01/29/2015 01:03 PM, zs wrote:
Detected an invalid packet at item INFO: Parser returned #f.
The answer may be RF settings are distorting your signal or others.I
want to ask a question.Which block in gnuradio give us this hint.Where
is the source code of the block?And have someone can help me to explain
this problem more details?Why will have this error/warning?
~/src/gnuradio ack-grep -C 3 an invalid packet
gr-digital/lib/packet_headerparser_b_impl.cc
80- );
81-
82- if (!d_header_formatter-header_parser(in, tags)) {
83:GR_LOG_INFO(d_logger, boost::format(Detected an invalid packet at
item %1%) % nitems_read(0));
84-message_port_pub(msg_port_id, pmt::PMT_F);
85- } else {
86-pmt::pmt_t dict(pmt::make_dict());
I guess your packet header is corrupt.
Best,
Bastian
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP B200 host BW with USB 3.0/2.0
How is that possible since only 8MHz can be placed over USB 2.0 ? On one hand I have a B200 which is supposed to deliver 56 MHz. On the other hand, for my final application, I am thinking of a low-cost host (such as BeagleBone Black) which I am afraid only has USB 2.0 My question was about getting 40MHz BW over USB 2.0 without tuning the central frequency of the USRP several times. Regards, Jorge On 29 January 2015 at 16:35, Ralph A. Schmid, dk5ras ra...@schmid.xxx wrote: I made tests with the bladeRF at 30 MHz bandwidth, and I was able to see the spectrum just fine, not matter if I used a USB2 or a USB3 cable. No hacks, no switching chunks of the spectrum, just using a standard receiver program. The lost samples are not a problem as longs as you do not want to listen in. Ralph. *From:* discuss-gnuradio-bounces+ralph=schmid@gnu.org [mailto: discuss-gnuradio-bounces+ralph=schmid@gnu.org] *On Behalf **Of *Jorge Gallo *Sent:* Thursday, January 29, 2015 4:07 PM *To:* Martin Braun *Cc:* GNURadio Discussion List *Subject:* Re: [Discuss-gnuradio] USRP B200 host BW with USB 3.0/2.0 Martin, The alternative of a USB 3.0 is not having 5 USRPs. It is just reading 5 times at different centrer frequencies in order to get 40MHz information although that information will not be gathered at the same time. For my application I just need to see the sprectrum. I do not need to demodulate data so that it would be fine to proceed that way. However i would rather get 40MHz in a row. Many thanks, Jorge On 29 January 2015 at 14:07, Martin Braun martin.br...@ettus.com wrote: On 01/29/2015 01:48 PM, Jorge Gallo wrote: I understand the given values of host bandwidth for each protocol: USB 2.0 8 (MS/s @ 16-bit I/Q) If you go down to 8-bit IQ, you will get twice that amount, if that's any help. USB 3.061.44 (MS/s @ 16-bit I/Q) However I would like to process 40MHz of analogue BW in GNURadio over USB 2.0 I fully understand a continuous reception is not possible to manage since it would require 40 IQ MS/s and I am limited to 8MS/s. However, is it possible to take snapshots of 40MHz over the time so that I am able to receive bits of 40MHz with USB 2.0 which are not continuous in time? Are there buffers in the FPGA that manage this kind of operation? None big enough for anything useful. It seems like attaching a USB3.0 connector would be simpler than running 5 USRPs? Not that I would complain about the sales :) M ___ 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] [coproc] Scheduling next CoProc WG Call
I've been a bit slow about organizing the first working group call of 2015, so let's get things rolling: I've selected a couple times in early Feb., and for those that are interested in helping to close out the outstanding issues created after GrCon'14, please indicate what times are good for you: http://whenisgood.net/2922ndn Doug -- Doug Geiger doug.gei...@bioradiation.net ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] OOT Python Block
I've created a python block that I've tested via command line. It passes all qa tests. I've also created an xml file for it and installed it. I followed every step the OOT Python Tutorial explains. I see the category and block in gnuradio-companion. When I use my block in a flowgraph, upon to executing the graph I get *AttirbuteError: 'module' object has no attribute 'my_module_name_here'* I've added the block build location to the PYTHONPATH variable and confirmed that I can import my module at a python command line. What do I not have set correctly and what is this error telling me? Thanks, Rich ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] INFO: Detected an invalid packet at item INFO: Parser returned #f
Hi Bastian:
Thank you so much.I use the ofdm example,and I think maybe the
crc is wrong as you said,thank you.
Best regards,
zs
At 2015-01-30 00:43:12, Bastian Bloessl bloe...@ccs-labs.org wrote:
Hi,
On 01/29/2015 03:13 PM, zs wrote:
Can you tell me,for general,in which circumstance,the packet header maybe
corrupt?
This is very hard to tell since I don't know what you are doing. I guess
you use a header_formatter in your flow graph and (for whatever reason)
its header_parse method returns false.
For example with the default header it looks like this happens if the
CRC is not correct
https://github.com/gnuradio/gnuradio/blob/master/gr-digital/lib/packet_header_default.cc#L132
At 2015-01-29 20:44:13, Bastian Bloessl bloe...@ccs-labs.org wrote:
Hi,
On 01/29/2015 01:03 PM, zs wrote:
Detected an invalid packet at item INFO: Parser returned #f.
The answer may be RF settings are distorting your signal or others.I
want to ask a question.Which block in gnuradio give us this hint.Where
is the source code of the block?And have someone can help me to explain
this problem more details?Why will have this error/warning?
~/src/gnuradio ack-grep -C 3 an invalid packet
gr-digital/lib/packet_headerparser_b_impl.cc
80- );
81-
82- if (!d_header_formatter-header_parser(in, tags)) {
83: GR_LOG_INFO(d_logger, boost::format(Detected an invalid packet at
item %1%) % nitems_read(0));
84- message_port_pub(msg_port_id, pmt::PMT_F);
85- } else {
86- pmt::pmt_t dict(pmt::make_dict());
I guess your packet header is corrupt.
Best,
Bastian
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP B200 host BW with USB 3.0/2.0
To be honest, I have no idea :) However I did not yet test this with the B210, as now USB3 works flawless. In the beginning the BladeRF was not compatible with my USB3 setup for whatever reason, so I had to stay with USB2 for a while until those issues were sorted out both in BladeRF software and VMware. Let’s see…FPGA loading really takes a while through a USB2 cable…HDSDR is starting…master_clock_rate=56e6… Tadaaa – here we go: http://dk5ras.dyndns.org/screenshots/B210_USB2.png with an USB 2 cable on an USB2 port. And in comparison http://dk5ras.dyndns.org/screenshots/B210_USB3.png with an USB3 cable on an USB3 port of the same PC. Same portion of the spectrum, same receiver location (just with a short wideband Delock 88451 antenna, sitting on my table), similar picture… Ralph. From: Jorge Gallo [mailto:jmig...@gmail.com] Sent: Thursday, January 29, 2015 4:44 PM To: Ralph A. Schmid, dk5ras Cc: Martin Braun; GNURadio Discussion List Subject: Re: [Discuss-gnuradio] USRP B200 host BW with USB 3.0/2.0 How is that possible since only 8MHz can be placed over USB 2.0 ? On one hand I have a B200 which is supposed to deliver 56 MHz. On the other hand, for my final application, I am thinking of a low-cost host (such as BeagleBone Black) which I am afraid only has USB 2.0 My question was about getting 40MHz BW over USB 2.0 without tuning the central frequency of the USRP several times. Regards, Jorge On 29 January 2015 at 16:35, Ralph A. Schmid, dk5ras ra...@schmid.xxx mailto:ra...@schmid.xxx wrote: I made tests with the bladeRF at 30 MHz bandwidth, and I was able to see the spectrum just fine, not matter if I used a USB2 or a USB3 cable. No hacks, no switching chunks of the spectrum, just using a standard receiver program. The lost samples are not a problem as longs as you do not want to listen in. Ralph. From: discuss-gnuradio-bounces+ralph=schmid@gnu.org mailto:schmid@gnu.org [mailto:discuss-gnuradio-bounces+ralph mailto:discuss-gnuradio-bounces%2Bralph =schmid@gnu.org mailto:schmid@gnu.org ] On Behalf Of Jorge Gallo Sent: Thursday, January 29, 2015 4:07 PM To: Martin Braun Cc: GNURadio Discussion List Subject: Re: [Discuss-gnuradio] USRP B200 host BW with USB 3.0/2.0 Martin, The alternative of a USB 3.0 is not having 5 USRPs. It is just reading 5 times at different centrer frequencies in order to get 40MHz information although that information will not be gathered at the same time. For my application I just need to see the sprectrum. I do not need to demodulate data so that it would be fine to proceed that way. However i would rather get 40MHz in a row. Many thanks, Jorge On 29 January 2015 at 14:07, Martin Braun martin.br...@ettus.com mailto:martin.br...@ettus.com wrote: On 01/29/2015 01:48 PM, Jorge Gallo wrote: I understand the given values of host bandwidth for each protocol: USB 2.0 8 (MS/s @ 16-bit I/Q) If you go down to 8-bit IQ, you will get twice that amount, if that's any help. USB 3.061.44 (MS/s @ 16-bit I/Q) However I would like to process 40MHz of analogue BW in GNURadio over USB 2.0 I fully understand a continuous reception is not possible to manage since it would require 40 IQ MS/s and I am limited to 8MS/s. However, is it possible to take snapshots of 40MHz over the time so that I am able to receive bits of 40MHz with USB 2.0 which are not continuous in time? Are there buffers in the FPGA that manage this kind of operation? None big enough for anything useful. It seems like attaching a USB3.0 connector would be simpler than running 5 USRPs? Not that I would complain about the sales :) M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org mailto: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] OOT Python Block
Hi Richard, I noticed the same problem with some blocks in my own OOT module. I do not know why, but if you change the lines in the GRC file to (if not already done) import import my_module.my_block_name_here/import makemy_module.my_block_name_here.my_block_name_here(…)/make (note the double block_name in make) I do not remember right, but it might also be sufficient to change only either one of the lines (you have to try on your own). You can try by calling the from python. E.g. IPython has tab completion and you can see by import my_module.tab (and so on for the make line), what block is how accessible. Regards Stephan Mit freundlichen Grüßen / Best regards Stephan Ludwig Robert Bosch GmbH Corporate Sector Research Advance Engineering, Communication Technology (CR/AEH4) Renningen 70465 Stuttgart GERMANY www.bosch.comhttp://www.bosch.com Tel. +49(711)811-8809 Fax +49(711)811-1052 Mobile +49(172)5630639 stephan.ludw...@de.bosch.commailto:stephan.ludw...@de.bosch.com Registered Office: Stuttgart, Registration Court: Amtsgericht Stuttgart, HRB 14000; Chairman of the Supervisory Board: Franz Fehrenbach; Managing Directors: Dr. Volkmar Denner, Dr. Stefan Asenkerschbaumer, Dr. Rolf Bulander, Dr. Stefan Hartung, Dr. Dirk Hoheisel, Christoph Kübel, Uwe Raschke, Wolf-Henning Scheider, Dr. Werner Struth, Peter Tyroller Von: discuss-gnuradio-bounces+stephan.ludwig2=de.bosch@gnu.org [mailto:discuss-gnuradio-bounces+stephan.ludwig2=de.bosch@gnu.org] Im Auftrag von Richard Bell Gesendet: Donnerstag, 29. Januar 2015 23:22 An: discuss-gnuradio@gnu.org Betreff: [Discuss-gnuradio] OOT Python Block I've created a python block that I've tested via command line. It passes all qa tests. I've also created an xml file for it and installed it. I followed every step the OOT Python Tutorial explains. I see the category and block in gnuradio-companion. When I use my block in a flowgraph, upon to executing the graph I get AttirbuteError: 'module' object has no attribute 'my_module_name_here' I've added the block build location to the PYTHONPATH variable and confirmed that I can import my module at a python command line. What do I not have set correctly and what is this error telling me? Thanks, Rich ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
