Flow graph using RTL-SDR or OSMOSDR source doesn't execute on 3.6.4.1

Hi All

I have a fresh install of ubuntu 12.04.2 LTS 64 bits with gnuradio
v3.6.4.1-185-g8fda7aca.
Flow graph using RTL-SDR or OSMOSDR source doesn’t execute. I get the
following log


Executing:
“/root/Other/GNU_Radio_Related/gnu_radio_examples/receiver/top_block.py”

linux; GNU C++ version 4.6.3; Boost_104601; UHD_003.005.002-65-g265daa58

Using Volk machine: avx_64_mmx_orc
gr-osmosdr 2d9e29ee (0.0.1git) gnuradio v3.6.4.1-185-g8fda7aca
built-in device types: file fcd rtl rtl_tcp uhd

Basically it does nothing after that, if I use the same Flow graph on
another machine running ubuntu 11.04 64 bits with gnuradio 3.6.2 all is
good, the log at launch is


Executing:
“/root/Other/GNU_Radio_Related/gnu_radio_examples/receiver/top_block.py”

linux; GNU C++ version 4.5.2; Boost_104200; UHD_003.005.002-6-gf1108bd2

gr_fir_ccc: using SSE
gr-osmosdr 871f0cc2 (0.0.1git) gnuradio 3.6.2
built-in device types: file fcd rtl rtl_tcp uhd
Using device #0 Generic RTL2832U SN: 77771111153705700
Found Elonics E4000 tuner
Exact sample rate is: 1000000.026491 Hz
Using Volk machine: avx_64_mmx_orc

gr_fir_fff: using SSE


Both machine have rtl-sdr and gr-osmosdr installed
If for 3.6.4.1 I replace the source sink by a UHD USRP one or a Signal
Source the Flow Graph executes properly

GNURadio has been installed manually by building the source as per the
wiki, same for rtl-sdr and gr-osmosdr

(Attached the flow graph in question)

Regards
Joe

On 05/04/2013 09:19 PM, Joe D wrote:


What does ‘lsusb’ report when you plug in your RTLSDR?

What does “rtl_test” report?


Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

HI Marcus

Here you go…this what I get

[email protected]:/# lsusb
Bus 001 Device 005: ID 0bda:2832 Realtek Semiconductor Corp. RTL2832U
DVB-T

[email protected]:/# rtl_test
Found 1 device(s):
0: Generic RTL2832U

Using device 0: Generic RTL2832U
Found Elonics E4000 tuner
Supported gain values (14): -1.0 1.5 4.0 6.5 9.0 11.5 14.0 16.5 19.0
21.5
24.0 29.0 34.0 42.0

Info: This tool will continuously read from the device, and report if
samples get lost. If you observe no further output, everything is fine.

Reading samples in async mode…

Joe

On ubuntu 12.04.2 LTS running 3.6.4.1 , I can load the
osmosdr_source_1rtl.grc and osmosdr_source_2rtl.grc, but same as my
initial
issue they don’t execute, I get


linux; GNU C++ version 4.6.3; Boost_104601; UHD_003.005.002-65-g265daa58

Using Volk machine: avx_64_mmx_orc
gr-osmosdr 2d9e29ee (0.0.1git) gnuradio v3.6.4.1-185-g8fda7aca
built-in device types: file fcd rtl rtl_tcp uhd


(Interestingly if I use the RTL2832 Source from gr-baz module I can
execute
the Flow Graph on 12.04.2 LTS running 3.6.4.1 , but performance are not
good at all compared to the RTLSDR Source one !! )

On the ubuntu 11.04 running 3.6.2, I can’t even load the
osmosdr_source_1rtl.grc and osmosdr_source_2rtl.grc, I get the following
error


Loading:
“/root/Other/GNU_Radio_Related/gnu_radio_examples/receiver/osmosdr_source_1rtl.grc”
Error: Specification mandate value for attribute data-pjax-transient,
line
22, column 40

Failure
Traceback (most recent call last):
File
“/usr/local/lib/python2.7/dist-packages/gnuradio/grc/gui/MainWindow.py”,
line 175, in new_page
file_path=file_path,
File
“/usr/local/lib/python2.7/dist-packages/gnuradio/grc/gui/NotebookPage.py”,
line 47, in init
initial_state = flow_graph.get_parent().parse_flow_graph(file_path)
File
“/usr/local/lib/python2.7/dist-packages/gnuradio/grc/base/Platform.py”,
line 109, in parse_flow_graph
ParseXML.validate_dtd(flow_graph_file, FLOW_GRAPH_DTD)
File
“/usr/local/lib/python2.7/dist-packages/gnuradio/grc/base/ParseXML.py”,
line 38, in validate_dtd
xml = etree.parse(xml_file, parser=parser)
File “lxml.etree.pyx”, line 2942, in lxml.etree.parse
(src/lxml/lxml.etree.c:54187)
File “parser.pxi”, line 1528, in lxml.etree._parseDocument
(src/lxml/lxml.etree.c:79485)
File “parser.pxi”, line 1557, in lxml.etree._parseDocumentFromURL
(src/lxml/lxml.etree.c:79768)
File “parser.pxi”, line 1457, in lxml.etree._parseDocFromFile
(src/lxml/lxml.etree.c:78843)
File “parser.pxi”, line 997, in
lxml.etree._BaseParser._parseDocFromFile
(src/lxml/lxml.etree.c:75698)
File “parser.pxi”, line 564, in
lxml.etree._ParserContext._handleParseResultDoc
(src/lxml/lxml.etree.c:71739)
File “parser.pxi”, line 645, in lxml.etree._handleParseResult
(src/lxml/lxml.etree.c:72614)
File “parser.pxi”, line 585, in lxml.etree._raiseParseError
(src/lxml/lxml.etree.c:71955)
XMLSyntaxError: Specification mandate value for attribute
data-pjax-transient, line 22, column 40


Regards
Joe

On Sun, May 5, 2013 at 4:29 PM, Sreeraj Rajendran

built-in device types: file fcd rtl rtl_tcp uhd

line 175, in new_page
“/usr/local/lib/python2.7/dist-packages/gnuradio/grc/base/ParseXML.py”, line
File “parser.pxi”, line 997, in

Sreeraj Rajendran

UHD_003.005.002-65-g265daa58

Using device #0 Generic RTL2832U SN: 77771111153705700

_______________________________________________

https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Joe, why don’t you use the build-gnuradio script. It takes care of
many details that you might have missed, and will almost certainly
result in a working system for RTLSDR when you’re done.

Indeed Marcus, I ll give the script a go as a last resort, i m curious
to
find out what causing it. To troubleshoot it I upgraded the working one
on
3.6.2 running on ubuntu 11.4 to 3.6.4.1, and guess what I m facing the
same
issue reported initialy , it looks like it is related to the gnuradio
version !

Hi,

Did you try example grc flowgraph provided by gr-osmosdr[1] on both of
your machines?

[1]available in gr-osmosdr/apps folder
(https://github.com/mjmdavis/gr-osmosdr/tree/master/apps)


Regards
Sreeraj Rajendran
http://home.iitb.ac.in/~rsreeraj


From: Joe D [email protected]
To: [email protected]
Sent: Sunday, 5 May 2013 6:49 AM
Subject: [Discuss-gnuradio] Flow graph using RTL-SDR or OSMOSDR source
doesn’t execute on 3.6.4.1

Hi All

I have a fresh install of ubuntu 12.04.2 LTS 64 bits with gnuradio
v3.6.4.1-185-g8fda7aca.
Flow graph using RTL-SDR or OSMOSDR source doesn’t execute. I get the
following log


Executing:
“/root/Other/GNU_Radio_Related/gnu_radio_examples/receiver/top_block.py”

linux; GNU C++ version 4.6.3; Boost_104601; UHD_003.005.002-65-g265daa58

Using Volk machine: avx_64_mmx_orc
gr-osmosdr 2d9e29ee (0.0.1git) gnuradio v3.6.4.1-185-g8fda7aca
built-in device types: file fcd rtl rtl_tcp uhd

Basically it does nothing after that, if I use the same Flow graph on
another machine running ubuntu 11.04 64 bits with gnuradio 3.6.2 all is
good, the log at launch is


Executing:
“/root/Other/GNU_Radio_Related/gnu_radio_examples/receiver/top_block.py”

linux; GNU C++ version 4.5.2; Boost_104200; UHD_003.005.002-6-gf1108bd2

gr_fir_ccc: using SSE
gr-osmosdr 871f0cc2 (0.0.1git) gnuradio 3.6.2
built-in device types: file fcd rtl rtl_tcp uhd
Using device #0 Generic RTL2832U SN: 77771111153705700
Found Elonics E4000 tuner
Exact sample rate is: 1000000.026491 Hz
Using Volk machine: avx_64_mmx_orc

gr_fir_fff: using SSE


Both machine have rtl-sdr and gr-osmosdr installed
If for 3.6.4.1 I replace the source sink by a UHD USRP one or a Signal
Source the Flow Graph executes properly

GNURadio has been installed manually by building the source as per the
wiki, same for rtl-sdr and gr-osmosdr

(Attached the flow graph in question)

Regards
Joe

Thanks for the advice Sreeraj, but would a sampling rate mismatch stop
the
flow graph from executing at all?

If In the same flow graph I substitute the RTL-SDR by the UHD USRP
Source
using the N210, the flow graph executes properly.

Joe

Thanks for the advice Sreeraj, but would a sampling rate mismatch stop
the flow graph from executing at all?

If In the same flow graph I substitute the RTL-SDR by the UHD USRP
Source using the N210, the flow graph executes properly.

Joe
The sample-rate mismatches will be different with the UHD devices.
2.8Msps is not a proper fraction of 100Msps, so UHD will pick
something “close”.

You really, really, need to make sure that the sample rates within your
flow-graph are consistent and correct. Doing anything other than
that will lead to rapid overruns or underruns at some early point in
the execution of your flowgraph. Having correct sample rates isn’t
optional, it’s absolutely vital to making sure your flow-graph
executes correctly, particularly when there are two hardware devices
involved–
in this case, an SDR source, and an audio sink. Everybody has to
“see” the correct sample rate–there’s no “kinda sorta close” operator
in DSP work.


Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org