Re: [Discuss-gnuradio] scheduled transmission using tx_timed_samples.cpp

[Josh Blum]

>>
>> Thanks josh, I got the idea. Also, I verified by looking at the LED "A" on
> USRP N210, which lights almost after 5 seconds. :)
> 
> I thought this should be discussed on gnruadio, so added gnuradio list. I
> want to convert tx_timed_samples.cpp into python. Can I do that? How can I
> make a "multi_usrp" ? Also, How can I use a block's data instead of buffer ?
> e.g
> tx_stream->send(DATA_FROM_SOME_BLOCK_IN_FLOWGRPAH, samps_to_send, md,
> timeout);
> 

The gr-uhd blocks that come with gnuradio integrate the USRP streaming
into gnuradio's data flow. You can create gnuradio blocks or use
existing blocks to interact with the USRP data streams. In addition, the
stream tags are used to control things like transmit time:

I think you will find some of the links here informative:

http://code.ettus.com/redmine/ettus/projects/uhd/wiki/GNU_Radio_UHD#Using-UHD-Software-with-GNU-Radio

> Further, what could be the minimum value of "seconds_in_future" ? In my
> case, When I set it to 0.3 or below I get following
> 
> Waiting for async burst ACK... fail
> 
> What does it mean ?
> 

The time delta between time on the device and time on a packet about to
be sent can actually be on the order of 100s of microseconds. However,
in this example, there is an expensive operation of setting up the
transmit streamer thats happening with in the time specified, so I think
thats why you are seeing 300 milliseconds fail. I think the transmit
time in this case has become "late" when the USRP interprets the packet.

-josh

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] scheduled transmission using tx_timed_samples.cpp

[Sam mite]

> Setting device timestamp to 0...
> > Start time is 0  7.801e-05
> > Sent packet: 363 samples
> > Sent packet: 363 samples
> > .
> > .
> > Sent packet: 363 samples
> > Sent packet: 363 samples
> > Sent packet: 199 samples
> >
>
> You will see the prints ASAP because the packets go out to the device
> ASAP. This means sent to device, not necessarily transmitted.
>
> > However, effect is observed on the following output
> >
> > Waiting for async burst ACK... success
> > Done!
> >
> > End time is 5  0.00197141.
>
> The time printed here after the ack is a little larger than 5 seconds,
> so you can see that the USRP must have held off transmission until 5
> seconds and then send the ACK for the end of burst.
>
> -josh
>
> Thanks josh, I got the idea. Also, I verified by looking at the LED "A" on
USRP N210, which lights almost after 5 seconds. :)

I thought this should be discussed on gnruadio, so added gnuradio list. I
want to convert tx_timed_samples.cpp into python. Can I do that? How can I
make a "multi_usrp" ? Also, How can I use a block's data instead of buffer ?
e.g
tx_stream->send(DATA_FROM_SOME_BLOCK_IN_FLOWGRPAH, samps_to_send, md,
timeout);

Further, what could be the minimum value of "seconds_in_future" ? In my
case, When I set it to 0.3 or below I get following

Waiting for async burst ACK... fail

What does it mean ?

Thanks


-- 

Regards,

Sam
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gnuradio-companion

[Sid Boyce]

On 06/05/13 02:09, Marcus D. Leech wrote:

Thanks again Marcus,
The problem with the build-gnuradio script is that it is set up to 
build on Ubuntu and Fedora but no good for openSUSE.

73 ... Sid.

When somebody sends me a reliable recipe for building on OpenSuse (and 
detecting that it's an OpenSuse system), I'll be happy to update

  build-gnuradio to support it.


--
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

I have the script so I'll have a look.
73 ... Sid.


--
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Senior Staff Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Flow graph using RTL-SDR or OSMOSDR source doesn't execute on 3.6.4.1

[Marcus D. Leech]

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 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] Flow graph using RTL-SDR or OSMOSDR source doesn't execute on 3.6.4.1

[Joe D]

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


On Mon, May 6, 2013 at 8:58 AM, Marcus D. Leech  wrote:

> 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 !
>>
>>  Well, I looked at your .grc file, and it has some problems.
>
> Since the input rate isn't evenly divisible by the output rate (44.1kHz),
> your decimations aren't going to work very well, since they don't
>   work out evenly.   It may sort of stagger through on some versions and
> not others.
>
> You might want to use any of the resampler blocks--like the fractional
> interpolator, to make certain that samples are being delivered
>   at the correct rates.
>
>
>
>
>
> --
> 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] gnuradio-companion

[Marcus D. Leech]

Thanks again Marcus,
The problem with the build-gnuradio script is that it is set up to 
build on Ubuntu and Fedora but no good for openSUSE.

73 ... Sid.

When somebody sends me a reliable recipe for building on OpenSuse (and 
detecting that it's an OpenSuse system), I'll be happy to update

  build-gnuradio to support it.


--
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] gnuradio-companion

[Sid Boyce]

On 06/05/13 00:39, Marcus D. Leech wrote:

On 23/04/13 14:46, Sid Boyce wrote:

# gnuradio-config-info -v
v3.6.4.1-106-gf1dbf510

On bot x86_64 and ARM gnuradio used to work now I get a pop-up 
complaining about PYTHONPATH.
"export PYTHONPATH=/usr/lib/python2.7" on ARM and "export 
PYTHONPATH=/usr/lib64/python2.7" on openSUSE doesn't help.


I even rebuilt gnuradio on x86_64 in case something in an update 
caused a problem.

73 ... Sid.

In fact, here's a fun little script I wrote a while back to find the 
appropriate pythonpath on your system.



--
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

Thanks again Marcus,
The problem with the build-gnuradio script is that it is set up to build 
on Ubuntu and Fedora but no good for openSUSE.

73 ... Sid.

--
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Senior Staff Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gnuradio-companion

[Sid Boyce]

On 06/05/13 00:34, Marcus D. Leech wrote:

On 23/04/13 14:46, Sid Boyce wrote:

# gnuradio-config-info -v
v3.6.4.1-106-gf1dbf510

On bot x86_64 and ARM gnuradio used to work now I get a pop-up 
complaining about PYTHONPATH.
"export PYTHONPATH=/usr/lib/python2.7" on ARM and "export 
PYTHONPATH=/usr/lib64/python2.7" on openSUSE doesn't help.


I even rebuilt gnuradio on x86_64 in case something in an update 
caused a problem.

73 ... Sid.



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

I rebuilt gnuradio, still getting the same error with gnuradio-companion.
"Cannot import gnuradio".
Presumably this is a python module which I don't have.

When I originally built gnuradio, gnuradio-companion worked on x86_64 
and on ARM.

The next time I launched it I got the error on both platforms.
Pointers please.
73 ... Sid.

--
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Senior Staff Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Sid:

If you had previously installed Gnu Radio from packaged binaries (with 
apt-get or the like), it will have installed under /usr


If you installed it from source (using build-gnuradio, or manually) 
all of its bits and pieces will be in /usr/local. Python packages will

  typically be installed under:

/usr/local/lib/python2.7/dist-packages

If you use build-gnuradio, one of the last things it does is try to 
figure out where things got installed, and suggest what you should set 
your

  PYTHONPATH to.



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

Thanks Marcus,
I found the problem, python2.7 and python3.2 and python3.3 are installed 
and it was picking python3.
"cmake -DPYTHON_EXECUTABLE=/usr/bin/python2.7 
-DPYTHON_INCLUDE_DIR=/usr/include/python2.7 
-DPYTHON_LIBRARY=/usr/lib64/libpython2.7.so -DCMAKE_INSTALL_PREFIX=/usr 
.." fixed it.

73 ... Sid.

--
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Senior Staff Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gnuradio-companion

[Marcus D. Leech]

On 23/04/13 14:46, Sid Boyce wrote:

# gnuradio-config-info -v
v3.6.4.1-106-gf1dbf510

On bot x86_64 and ARM gnuradio used to work now I get a pop-up 
complaining about PYTHONPATH.
"export PYTHONPATH=/usr/lib/python2.7" on ARM and "export 
PYTHONPATH=/usr/lib64/python2.7" on openSUSE doesn't help.


I even rebuilt gnuradio on x86_64 in case something in an update 
caused a problem.

73 ... Sid.

In fact, here's a fun little script I wrote a while back to find the 
appropriate pythonpath on your system.



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

#!/bin/sh
#
# Setup PYTHONPATH
#
function pythonpath {
PYTHONPATH=unset
for mach in 64 ""
do
for lib in /usr/local/lib /opt/lib /usr/lib
do
for vers in 2.8 2.7 2.6 2.5
do
for pkg in site-packages dist-packages
do
td=${lib}${mach}/python${vers}/${pkg}
if [ -d $td/gnuradio ]
then
PYTHONPATH=$td
break
fi
done
if [ $PYTHONPATH != unset ]
then
break
fi
done
if [ $PYTHONPATH != unset ]
then
break
fi
done
if [ $PYTHONPATH != unset ]
then
break
fi
done
}
pythonpath
echo PYTHONPATH should be $PYTHONPATH

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gnuradio-companion

[Sid Boyce]

On 23/04/13 14:46, Sid Boyce wrote:

# gnuradio-config-info -v
v3.6.4.1-106-gf1dbf510

On bot x86_64 and ARM gnuradio used to work now I get a pop-up 
complaining about PYTHONPATH.
"export PYTHONPATH=/usr/lib/python2.7" on ARM and "export 
PYTHONPATH=/usr/lib64/python2.7" on openSUSE doesn't help.


I even rebuilt gnuradio on x86_64 in case something in an update 
caused a problem.

73 ... Sid.



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

I rebuilt gnuradio, still getting the same error with gnuradio-companion.
"Cannot import gnuradio".
Presumably this is a python module which I don't have.

When I originally built gnuradio, gnuradio-companion worked on x86_64 
and on ARM.

The next time I launched it I got the error on both platforms.
Pointers please.
73 ... Sid.

--
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Senior Staff Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks

<>___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Flow graph using RTL-SDR or OSMOSDR source doesn't execute on 3.6.4.1

[Joe D]

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 !
On May 5, 2013 11:29 PM, "Marcus D. Leech"  wrote:

> **
>
>   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  > wrote:
>
>>
>>  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 
>> *To:* discuss-gnuradio@gnu.org
>> *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
>> go

[Discuss-gnuradio] Attempts at Receiving and Decoding MSF

[Iain Young, G7III]

Hi Folks,

I have been spent the last couple of days working on agnuradio
flowgraph to receive the  MSF Time Signal here in the UK on 60kHz,
using it as a learning experience.

I'm hoping that I can eventually use similar code to receive DCF and
also RBU, and the compare the results from my hardware decoders (Not
to mention an IRIG receiver as MIKES in Finland transmits IRIG-B, and
I can hear that on 25 MHz)

The approach I have taken thus far is to tune 1kHz OFF of 60, and use
a Goertzel filter tuned to 1kHz, before sending onto a probe, and
eventually onto a pipe which the other end connects to an external
program to identify the meaning of each 1 or 0, combine them, then
send the info onwards to NTP via the SHM driver.

(Future RBU and IRIG work is the reason to tune off by 1k, then use a
Goertzel filter, as RBU uses 100Hz and 312.5Hz tones to indicate 0 and 1
respectively, not carrier on/off, and IRIG-B modulates a 1kHz signal
AIUI)

There are screenshots at flowgraphs at the following URLs:

http://hal.g7iii.net/GRC/MSF_SDR/MSF_SDR_Screenshot.png
http://hal.g7iii.net/GRC/MSF_SDR/MSF_SDR.png
http://hal.g7iii.net/GRC/MSF_SDR/MSF_SDR.grc

The top left waterfall is the raw 192kHz from my FunCube Dongle Pro
Plus, centered on 150kHz. So MSF is -90kHz away, so I have a FIR
filter set at -59k (so MSF is at 1kHz in the pass band).

I follow the FIR filter with a quick re-sample to 200k purely to make
calculations as to how many samples cover 100ms or 200ms easy. I follow
the re-sampler by a BPF that actually works as a LPF with a high
cut off of 10kHz. The output of this can be seen in the lower
left waterfall

(Note, the multiply by Consts before the WXGUI waterfalls are purely
there to act as an amplifier to make seeing the signals easier!)

This is then followed by a tight BPF between 900 and 1100 Hz, before
being converted to real for the Goertzel filter, the output of
which can be seen in the top right waterfall)

In the bottom left, there is a FFT showing the same data,
but after it has been passed through a Complex to Mag^2 block, and
is the same as is fed to the Prob Avg Mag^2 block.

This gets picked up by the msf_carrier function probe, and the light_1k
checkbox gets set appropriately to indicate if the threshold has been
exceeded or not for visual status display and debug.

The Constant Source also references the light_1k variable, and is
converted to a float, and then a char for sending out to the pipe.


Now, I believe I am 80-90 % of the way there, I've had a few issues
with getting the right rate post the Goertzel filter, and deciding how
much of the processing should be done in gnuradio, and how much should
be done by an external program.

(EG do I increase the length of the Goertzel filter to get the binary
1s and 0s of the time code out of gnuradio, increasing the selectivity
or do I count the number of 1s and 0s samples in the external program)

The other big issue has been setting the threshold levels correctly, 
which has been frustrating to say the least :)



What I was wondering from those better versed in these things than I
was, is this the general approach they would take ? Or is there a better
way ? What would they do differently ?

(Yes the amount of Complex <-> Real conversions could probably be
reduced, but this is more early development and debug stage, and
certainly would be done once I have it working reliably.)


Best Regards

Iain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Flow graph using RTL-SDR or OSMOSDR source doesn't execute on 3.6.4.1

[Marcus D. Leech]

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 
mailto:srees4sr...@yahoo.co.in>> wrote:



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 mailto:joer...@gmail.com>>
*To:* discuss-gnuradio@gnu.org 
*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_cc

Re: [Discuss-gnuradio] Build error

[Marcus D. Leech]

Hi Les,

try to build with verbose output enabled, to see if there might be 
more errors/warnings. If I remember correctly you need to run 
something like this:

make VERBOSE=1
If it does not work, search the list/website on how to turn verbose 
building on.


Yours
Martin

PS: Please make sure you answer to the list and not to an individual 
person. This way everyone on the list can help you and it is archived 
fur future reference, if someone has the same problem.


Les is building on a Pentium III system, which likely will be no end of 
grief, even if he has the patience to wait for the compile to finish.


A PIII system is wy underpowered for doing anything with Gnu Radio, 
and the fact that the longest compile stage hadn't finished after
  24 hours is a clue that it'll be almost useless actually running Gnu 
Radio.





--
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] Build error

[Martin Lülf]

Hi Les,

try to build with verbose output enabled, to see if there might be more 
errors/warnings. If I remember correctly you need to run something like 
this:

make VERBOSE=1
If it does not work, search the list/website on how to turn verbose 
building on.


Yours
Martin

PS: Please make sure you answer to the list and not to an individual 
person. This way everyone on the list can help you and it is archived 
fur future reference, if someone has the same problem.



Am 05.05.2013 07:47, schrieb Les Barker:

Hi Martin

Thanks for the reply

I had the same thought, that it was only an error message, BUT the
computer appears to go into a "loop" after that message and after more
than 24 hours the "build" has not progressed any further.
Must I just leave it to carry on, or could there be some other problem
that I am not aware of?

I really appreciate your help as I am into an area of which I have very
little knowledge, but a lot of interest.

Regards
Les


- Original Message - From: "Martin Lülf" 
To: 
Sent: Saturday, May 04, 2013 2:44 PM
Subject: Re: [Discuss-gnuradio] Build error


Am 04.05.2013 14:32, schrieb Les Barker:

Hi All
I turn to this discussion group in the hopes that someone can help! I am
trying to build gnuradio on the way to achieving a working GQRX SDR
program.
I have tried various releases of gnuradio, including the latest,
gnuradio-3.6.4.1, all with the same result i.e.
[ 40%] Building CXX object
gnuradio-core/src/lib/swig/CMakeFiles/_gnuradio_core_general.dir/gnuradio_core_generalPYTHON_wrap.cxx.o


/home/les/sdr/gnuradio-3.6.4.1/build/gnuradio-core/src/lib/swig/gnuradio_core_generalPYTHON_wrap.cxx:

In function ˜void init_gnuradio_core_general():"

/home/les/sdr/gnuradio-3.6.4.1/build/gnuradio-core/src/lib/swig/gnuradio_core_generalPYTHON_wrap.cxx:323844:21:

warning: variable "md" set but not used [-Wunused-but-set-variable]

I am using Ubuntu 12.04 on a 32 bit Pentium 3 desktop PC.

I am new to Linux and definitely not a proficient programmer, just a
radio ham who would like to use Gqrx SDR.

Does anyone have a solution to the problem?

Thanks

Les ZS2VA


Hi Les,

the lines you posted are compiler warnings, but not errors. That means
that the build process should run through without trouble, or there is a
real error further down the line.

These compiler warnings are there to notify you about possible (logic)
mistakes in the code, but since they occur in the SWIG generated
(PYTHON_wrap.cxx) code I suppose it will be very hard to fix them, so
just ignore them.

Yours
Martin

___
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] Flow graph using RTL-SDR or OSMOSDR source doesn't execute on 3.6.4.1

[Joe D]

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
wrote:

>
> 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 
> *To:* discuss-gnuradio@gnu.org
> *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: 153705700
> Found Elonics E4000 tuner
> Exact sample rate is: 100.026491 Hz
> Using Volk machine: avx_64_

Re: [Discuss-gnuradio] USRP2 + WBX for DVB-T replaying

[Dinos Pastos]

Thanks for the info
I do need it to be real time actually
As for your concerns about the Emm. All I need to do is disable one not
edit it, so it's either a re package of the steam or a jam of a specific
header.

Can you point me to a working dvb-t project?

Thanks again


On Saturday, May 4, 2013, Marcus Müller wrote:

> Hi Dino,
>
> DVB-T works in the UHF / VHF frequency bands, something you can tune
> your wbx at without problems.
> Bandwidth is about 8MHz (if I'm not mistaken), so that's low enough.
> Since it sounds like you'll be doing stuff offline (not in realtime),
> processing power is not a factor for your problem, either.
>
> DVB-T generally uses OFDM with large numbers of bins (2^11 or 2^13-bin
> fft), generous guard intervals and whatnot. A moderately complex system,
> but someone has already implemented a dvb-t modulator in GNU Radio[1], you
> can take a look at that, but I doubt it would work with current versions of
> GNU Radio.
>
> Regarding to your EMM "hint": You do have to realize that EMMs are rather
> "high level" concepts; you need to encode them into a data stream, mux them
> together with the video stream, encode that whole thing, map it to the
> correct OFDM carriers and transmit that.
> Since what we're talking about are messages meant to inform decryption
> devices about their working state, I guess it won't be as easy as
> replaying EMMs you captured, since it most probably carries keys for
> specific content. Then, on the other hand, TV encryption in the 90s has
> gained notority for being broken shortly after deployment, so this is
> actually an interesting field of research for someone with a cryptographic
> background (which I can't claim to have).
>
> Happy hacking
>
> Marcus
>
>
> [1] PELLEGRINI, Vincenzo; BACCI, Giacomo; LUISE, Marco. Soft-dvb: A
> fully-software gnuradio-based etsi dvb-t modulator. Proc. WSR, 2008, 8. Jg.
> Am 03.05.2013 23:35, schrieb Dinos Pastos:
>
>> Hi there,
>>
>> I have a USRP2 with WBX board which has been sitting around doing nothing.
>> I was wondering if it is possible to use this hardware to get a live
>> DVB-T signal and replay it back.
>>
>> What I want to do is to intercept entitlement management messages and
>> modify/remove them on the fly.
>>
>> Please let me know if there is such support with this hardware or even a
>> previous project that tackles this request.
>>
>> Regards
>>
>> Dino
>>
>>
>> __**_
>> 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] Flow graph using RTL-SDR or OSMOSDR source doesn't execute on 3.6.4.1

[Sreeraj Rajendran]

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 
To: discuss-gnuradio@gnu.org 
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: 153705700
Found Elonics E4000 tuner
Exact sample rate is: 100.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



___
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