[Discuss-gnuradio] liquid-dsp in gnuradio... why?

[Alexandru Csete]

Greetings,

I notice more an more talk about integration of liquid-dsp into
gnuradio and apparently there is already a gr-liquiddsp out of tree
module on github.

I have known of liquid-dsp for quite some time now. It is my first
choice when I need SDR in pure C and I have nothing but the utmost
respect for the documentation it comes with.

I am however wondering what is the rationale behind integrating
liquid-dsp into gnuradio. From what I can see, most if not all
functionality in liquid-dsp is already available in gnuradio. Having
duplicated functionality is almost always wrong and hardly contributes
to clarity.

I am probably missing something or just misunderstand the situation,
so please enlighten me :)

Alex

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

[Discuss-gnuradio] libusb_init error

[Dincer Beken]

Hi,

I installed GR 3.6 from the build-gnuradio script but whenever I want to use 
uhd:usrp_source I get:

Traceback (most recent call last):
  File "/home/dincer/gnuradio/gr-lte/grc/usrp_rx.py", line 131, in 
tb = usrp_rx()
  File "/home/dincer/gnuradio/gr-lte/grc/usrp_rx.py", line 74, in __init__
channels=range(1),
  File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py", line 
116, in constructor_interceptor
return old_constructor(*args)
  File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py", line 
3051, in usrp_source
return _uhd_swig.usrp_source(*args)
RuntimeError: AssertionError: libusb_init(&_context) == 0
  in libusb_session_impl::libusb_session_impl()
  at /home/dincer/uhd/host/lib/transport/libusb1_base.cpp:39

I can ping the USRP.

Does anyone know the reason?  In libusb1_base, I am getting "0" as _context.

Thanks,




Mit freundlichen Grüßen,
Dincer Beken

e-mail: dbe...@blackned.de
tel.: +49 833199596-26

[cid:image001.png@01CD3E54.B249FA20]

blackned gmbh · www.blackned.de
zentrale: dorfstrasse 3 · 88416 erlenmoos
niederlassung: am hartholz 21 · 82239 alling

geschäftsführer: timo haas · josef stadler · hrb ulm 724147


Der Inhalt dieser E-Mail ist ausschließlich für den bezeichneten Adressaten 
bestimmt.
Wenn Sie nicht der vorgesehene Adressat dieser E-Mail oder dessen Vertreter 
sein sollten,
bitten wir Sie, sich in diesem Falle umgehend mit dem Absender der E-Mail in 
Verbindung
zu setzen und diese Daten von Ihrem Computer zu löschen. Bitte beachten Sie, 
dass jede
Form von Veröffentlichung, Vervielfältigung oder Weitergabe des Inhalts dieser 
E-Mail unzulässig ist.

Die im Geschäftsverkehr von Unternehmern übliche Vertraulichkeit
kann bei der Übermittlung von Daten per E-mail nicht gewahrt werden.
Bitte prüfen Sie, welche Informationen Sie uns per E-mail übermitteln.

This e-mail may contain information which is priviledged or confidential.
If you are not the named addressee of this e-mail, please notify us immediately 
and destroy
the document without reading, copying or disclosing its contents to any other 
person.


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

Re: [Discuss-gnuradio] libusb_init error

[Dincer Beken]

To add:

I am using a N210 with (Ethernet). I am not sure, If I really need this.



Von: Dincer Beken
Gesendet: Freitag, 11. Oktober 2013 13:23
An: Discuss-gnuradio@gnu.org
Betreff: libusb_init error

Hi,

I installed GR 3.6 from the build-gnuradio script but whenever I want to use 
uhd:usrp_source I get:

Traceback (most recent call last):
  File "/home/dincer/gnuradio/gr-lte/grc/usrp_rx.py", line 131, in 
tb = usrp_rx()
  File "/home/dincer/gnuradio/gr-lte/grc/usrp_rx.py", line 74, in __init__
channels=range(1),
  File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py", line 
116, in constructor_interceptor
return old_constructor(*args)
  File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py", line 
3051, in usrp_source
return _uhd_swig.usrp_source(*args)
RuntimeError: AssertionError: libusb_init(&_context) == 0
  in libusb_session_impl::libusb_session_impl()
  at /home/dincer/uhd/host/lib/transport/libusb1_base.cpp:39

I can ping the USRP.

Does anyone know the reason?  In libusb1_base, I am getting "0" as _context.

Thanks,




Mit freundlichen Grüßen,
Dincer Beken

e-mail: dbe...@blackned.de
tel.: +49 833199596-26

[cid:image001.png@01CD3E54.B249FA20]

blackned gmbh · www.blackned.de
zentrale: dorfstrasse 3 · 88416 erlenmoos
niederlassung: am hartholz 21 · 82239 alling

geschäftsführer: timo haas · josef stadler · hrb ulm 724147


Der Inhalt dieser E-Mail ist ausschließlich für den bezeichneten Adressaten 
bestimmt.
Wenn Sie nicht der vorgesehene Adressat dieser E-Mail oder dessen Vertreter 
sein sollten,
bitten wir Sie, sich in diesem Falle umgehend mit dem Absender der E-Mail in 
Verbindung
zu setzen und diese Daten von Ihrem Computer zu löschen. Bitte beachten Sie, 
dass jede
Form von Veröffentlichung, Vervielfältigung oder Weitergabe des Inhalts dieser 
E-Mail unzulässig ist.

Die im Geschäftsverkehr von Unternehmern übliche Vertraulichkeit
kann bei der Übermittlung von Daten per E-mail nicht gewahrt werden.
Bitte prüfen Sie, welche Informationen Sie uns per E-mail übermitteln.

This e-mail may contain information which is priviledged or confidential.
If you are not the named addressee of this e-mail, please notify us immediately 
and destroy
the document without reading, copying or disclosing its contents to any other 
person.


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

[Discuss-gnuradio] why the code in gnuradio in 3.6 cannot work in 3.7?

[Yingjie Chen]

Hi guy,

I have updated the gunradio to 3.7.1, but fond the c++ block name and style
changed a litter bit. like ofdm_insert_preamble.cc is changed to
ofdm_instert_preamble_impl.cc. When I add some codes in general work
funciton, and use the command *make and make install *it in build directory
as usual in gnuradio 3.6, I cannot see any change after adding my personal
code. I guess the build fire is not installed. what is happening in 3.7?

Any help would be appreciated.

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

Re: [Discuss-gnuradio] controlling flowgraph

[Nemanja Savic]

I still can't find solution so any suggestion would be good.

Best,
Nemanja


On Thu, Oct 10, 2013 at 5:26 PM, Nemanja Savic  wrote:

> Ok, I have found button :), but the problem is now following. Part of my
> script looks like this:
>
> def aaa(a):
> global state
> state = 1
>
> state = 1
> data = [0]
> if __name__ == '__main__':
> parser = OptionParser(option_class=eng_option, usage="%prog:
> [options]")
> (options, args) = parser.parse_args()
> tb = top_block()
> while(True):
> if state == 1:
> print "aa"
> state = 0
> data.append(0)
> tb.blocks_vector_source_x_0.set_data(data)
> tb.run()
> print tb.blocks_vector_sink_x_0.data()
>
> aaa is callback function called when the button is pressed.
> What i want to achieve is following:
> when flowgraph starts i don't want any transmiton, I just want to see gui.
> when i press the button, then one frame should be sent.
> when i press again the button another frame should be sent.
> ...
>
> Is this possible? In example above I don't see gui at all.
>
>
> On Thu, Oct 10, 2013 at 12:40 PM, Nemanja Savic wrote:
>
>> Hi all guys,
>>
>> I wanted to implement a ask transmitter and a button for triggering
>> transmition of a single frame of data. My idea was to do that with a sort
>> of state machine and a button, but as far as i can see there is no button
>> in wx gui blocks. How do uo usually do this?
>>
>> Many thanks,
>>
>> --
>> Nemanja Savić
>>
>
>
>
> --
> Nemanja Savić
>



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

Re: [Discuss-gnuradio] Question about "extra" header

[Bennett, David S. (Scott)]

> 
> The extra_dict argument to the constructor is just a way to add more data to
> the extra part of the header; any more data you want to add that wouldn't
> be in there normally.
> 
> The extra part of the header collects any tags observed, so the USRP will
> generate tags like rx_freq that will go into the header.
> 
> The metadata section of the manual has a pretty good explanation of how it
> works:
> 
> http://gnuradio.org/doc/doxygen/page_metadata.html
> 
> Tom

Tom,

Thanks for the note.  As a kind of "hack" programmer, stuff like that isn't 
always clear to me on the first (or second, or third, or etc.) time through 
reading it - usually it's because I don't know exactly what I'm looking for.  
But I was able this morning to add the additional tags (at least a test of them 
with the same data types) to the usrp_source_impl.cc source code, and it looks 
like, when I read the metadata with the gr_read_file_metadata.py script, I can 
read out what I wrote in.  So that's progress.  I guess the extra tags as 
sourced from the USRP are handled by the parser because the expected header 
length is different from where the actual data starts (from the 'strt' tag), 
and the script interprets that additional information as extra header.

I appreciate your help.

Thanks,
Scott

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

Re: [Discuss-gnuradio] controlling flowgraph

[Nemanja Savic]

When want to use method Start, that is defined for top_block_gui class, i
always get this error:

AttributeError: 'gr_top_block_sptr' object has no attribute 'Start'
[savi_ne@ts-070046nl GRC]$ gvim
/usr/local/lib64/python2.6/site-packages/gnuradio/gr/top_block.py

But it is clear that tb is of top_block_gui, and there is no error for
using Run method.
Why is this so?


On Fri, Oct 11, 2013 at 3:26 PM, Nemanja Savic  wrote:

> I still can't find solution so any suggestion would be good.
>
> Best,
> Nemanja
>
>
> On Thu, Oct 10, 2013 at 5:26 PM, Nemanja Savic  wrote:
>
>> Ok, I have found button :), but the problem is now following. Part of my
>> script looks like this:
>>
>> def aaa(a):
>> global state
>> state = 1
>>
>> state = 1
>> data = [0]
>> if __name__ == '__main__':
>> parser = OptionParser(option_class=eng_option, usage="%prog:
>> [options]")
>> (options, args) = parser.parse_args()
>> tb = top_block()
>> while(True):
>> if state == 1:
>> print "aa"
>> state = 0
>> data.append(0)
>> tb.blocks_vector_source_x_0.set_data(data)
>> tb.run()
>> print tb.blocks_vector_sink_x_0.data()
>>
>> aaa is callback function called when the button is pressed.
>> What i want to achieve is following:
>> when flowgraph starts i don't want any transmiton, I just want to see gui.
>> when i press the button, then one frame should be sent.
>> when i press again the button another frame should be sent.
>> ...
>>
>> Is this possible? In example above I don't see gui at all.
>>
>>
>> On Thu, Oct 10, 2013 at 12:40 PM, Nemanja Savic wrote:
>>
>>> Hi all guys,
>>>
>>> I wanted to implement a ask transmitter and a button for triggering
>>> transmition of a single frame of data. My idea was to do that with a sort
>>> of state machine and a button, but as far as i can see there is no button
>>> in wx gui blocks. How do uo usually do this?
>>>
>>> Many thanks,
>>>
>>> --
>>> Nemanja Savić
>>>
>>
>>
>>
>> --
>> Nemanja Savić
>>
>
>
>
> --
> Nemanja Savić
>



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

[Discuss-gnuradio] GnuRadio flowgraphs in workerthread

[Alex3371]

Hello guys,

would it affect the performance of my GNURadio-programm negatively if I
tried to run my GNURadio flowgraphs in a workerthread instead of the
mainthread. In the mainthread I would like to implement a custom wxPython
GUI.

Also, I still do not understand what the happens when I call wait() and/or
stop(). I have two flowgraphs, one for receiving and one for transmitting
with the USRP2. Both use a gr.head block and run to completion after they
have proccessed a certain ammount of samples. I did some testing and it
seems to work fine. But still I would like to know if the following lines of
Code make any sense:

main():

receiver = receiver_class()

transmitter = transmitter_class()

while(1):

__receiver.run()
__transmitter.run()
__# reset the head blocks and some other stuff:
__update_attributes()

Can I use run() OR should I use start() + wait() OR start(), wait() + stop()
?

Regards
Alex Peterson





--
View this message in context: 
http://gnuradio.4.n7.nabble.com/GnuRadio-flowgraphs-in-workerthread-tp44121.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

Re: [Discuss-gnuradio] why the code in gnuradio in 3.6 cannot work in 3.7?

[Martin Braun (CEL)]

Read http://gnuradio.org/redmine/projects/gnuradio/wiki/Move_3-6_to_3-7

MB

On Fri, Oct 11, 2013 at 09:25:53PM +0800, Yingjie Chen wrote:
> Hi guy,
> 
> 
> I have updated the gunradio to 3.7.1, but fond the c++ block name and style
> changed a litter bit. like ofdm_insert_preamble.cc is changed to
> ofdm_instert_preamble_impl.cc. When I add some codes in general work funciton,
> and use the command make and make install it in build directory as usual in
> gnuradio 3.6, I cannot see any change after adding my personal code. I guess
> the build fire is not installed. what is happening in 3.7?
> 
> 
> Any help would be appreciated.
> 
> 
> Best,
> 
> Kay
> 

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


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


pgpG4BCqiRkAd.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GNU Chirp Sounder version 1.23

[Juha Vierinen]

Hi,

My gnuradio hackfest project was to migrate code to 3.7. With the help of a
lot of the other more programming savvy participants, I managed to migrate
everything fairly cleanly. As a byproduct of this, my chirp sounder
receiver code now works with gnuradio 3.7 too! I did a lot of cleanup and
removed the dependency on GNU R. I also added a new feature that allows you
to filter out HF broadcast band interference before chirp downconversion.

I wrote a small posting about the release here (with a nice video using the
new HF broadcast band filtering):
http://kaira.sgo.fi/

And the new version of the code can be found here:
http://www.sgo.fi/~j/gnu_chirp_sounder/

You should be able to get this working if you have a N200 series device, a
GPSDO, and a broad band HF antenna (it doesn't have to be excellent).

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

Re: [Discuss-gnuradio] Again bladerf / gqrx / gr-osmosdr

[Jared Clements]

Yeah, I would take that to the osmocom-sdr list, that's where those
developers usually hang out.

Jared
On Oct 10, 2013 9:22 PM, "Ralph A. Schmid, dk5ras"  wrote:

> What is “directly”? J At least I can use it before updating all this
> stuff, GR can RX and TX just fine, but through GR-osmosdr.
>
> It looks to me that osmosdr may be the deeper involved in the problem,
> when not updating this one nothing wrong is happening.
>
> ** **
>
> At the moment I am on latest revision with bladerf and gqrx, gqrx works,
> gnuradio works. Just updating gr-osmosdr will break things.
>
> ** **
>
> Ralph.
>
> ** **
>
> ** **
>
> ** **
>
> *From:* Jared Clements [mailto:jared.cleme...@gmail.com]
> *Sent:* Friday, 11 October, 2013 02:21
> *To:* Ralph A. Schmid, dk5ras
> *Cc:* GNURadio Discussion List; Brian Padalino
> *Subject:* Re: [Discuss-gnuradio] Again bladerf / gqrx / gr-osmosdr
>
> ** **
>
> Those look a lot like some errors I was getting a short while ago.  They
> popped up while the compiler was at the linking stage.  My errors were in
> the CMakeList.txt files, which were somewhat opaque to me.
>
> By elimination, can you verify that gnuradio can access your bladerf
> directly?  Say a source to an fft plot, tuned to a local FM radio station?
> 
>
> Jared
>
> On Oct 10, 2013 11:13 AM, "Ralph A. Schmid, dk5ras" 
> wrote:
>
> It stays the same, after uninstalling everything, pulling fresh repos,
> building and installing bladeref, gr-osmosdr and gqrx in this order the
> message when building gqrx remains
>
> /usr/local/lib/libgnuradio-osmosdr.so: undefined reference to
> `bladerf_fpga_version'
> /usr/local/lib/libgnuradio-osmosdr.so: undefined reference to
> `bladerf_fw_version'
> collect2: ld returned 1 exit status
> make: *** [gqrx] Error 1
> ras@ubuntu:~/gqrx$
>
> Ralph.
>
> > -Original Message-
> > From: Brian Padalino [mailto:bpadal...@gmail.com]
> > Sent: Thursday, 10 October, 2013 15:38
> > To: Ralph A. Schmid, dk5ras
> > Cc: Alexandru Csete; GNURadio Discussion List
> > Subject: Re: [Discuss-gnuradio] Again bladerf / gqrx / gr-osmosdr
> >
> > On Thu, Oct 10, 2013 at 1:52 AM, Ralph A. Schmid, dk5ras
> 
> > wrote:
> > > Hi,
> > >
> > >> Looks like there is something missing from your libbladeRF.so.  The
> > >> repository shows they were added on October 2nd.  Are you sure you're
> > >> building the latest stuff?
> > >
> > > Should be the latest, when doing a git pull right before building it.
> > > I did not yet delete the whole BladeRF folder and clone into a totally
> > > new folder, maybe this helps?
> >
> > I always recommend blowing away the build directory and rerunning cmake
> ..,
> > make, sudo make install.
> >
> > That is the best way I've found to make sure things are fresh.
> >
> > I just rebuilt against everything last night and things seemed fine to
> me.
> Others
> > have also reported success.
> >
> > Let me know how it goes.
> >
> > Brian
>
>
> ___
> 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] liquid-dsp in gnuradio... why?

[Johnathan Corgan]

On 10/11/2013 04:23 AM, Alexandru Csete wrote:

> I am probably missing something or just misunderstand the situation,
> so please enlighten me :)

This is more Tom's area, but I'll comment since he's off enjoying life
and (hopefully) ignoring GNU Radio for a bit.

While there is a lot of overlap between existing signal processing
capabilities in GNU Radio and liquid-dsp, we are interested in wrapping
some portions of it into the GNU Radio SDR framework.  In particular,
the library has a number of FEC codecs and low-level math routines that
would help round-out GNU Radio's functionality.

Also of interest is the liquid-fpm fixed-point math library, which could
help GNU Radio operate in embedded environments that do not have
floating point capabilities.

The experimental work done with gr-liquiddsp is being done out-of-tree
and we have *not* yet worked out a development plan to incorporate it.

-- 
Johnathan Corgan, Corgan Labs
SDR Training and Development Services
http://corganlabs.com
<>

signature.asc
Description: OpenPGP digital signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNU Chirp Sounder version 1.23

[Marcus Leech]

Cool. 
Any volunteers to convert gr-ra_blocks to 3.7 for me?    [Crickets...]
 
 
on Oct 11, 2013, Juha Vierinen  wrote:


Hi,
 
My gnuradio hackfest project was to migrate code to 3.7. With the help of a lot of the other more programming savvy participants, I managed to migrate everything fairly cleanly. As a byproduct of this, my chirp sounder receiver code now works with gnuradio 3.7 too! I did a lot of cleanup and removed the dependency on GNU R. I also added a new feature that allows you to filter out HF broadcast band interference before chirp downconversion. 
 
I wrote a small posting about the release here (with a nice video using the new HF broadcast band filtering):
http://kaira.sgo.fi/
 
And the new version of the code can be found here:
http://www.sgo.fi/~j/gnu_chirp_sounder/

 
You should be able to get this working if you have a N200 series device, a GPSDO, and a broad band HF antenna (it doesn't have to be excellent). 
 
juha


___Discuss-gnuradio mailing listDiscuss-gnuradio@gnu.orghttps://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] GnuRadio flowgraphs in workerthread

[Johnathan Corgan]

On 10/11/2013 07:52 AM, Alex3371 wrote:

> would it affect the performance of my GNURadio-programm negatively if
> I tried to run my GNURadio flowgraphs in a workerthread instead of
> the mainthread. In the mainthread I would like to implement a custom
> wxPython GUI.

It is entirely possible to instantiate a GNU Radio flowgraph in a
separate thread from the main one, though it's not clear in your use
case if it is needed. There is no performance impact. The runtime will
create individual threads for each block anyway.

> Also, I still do not understand what the happens when I call wait() 
> and/or stop(). I have two flowgraphs, one for receiving and one for 
> transmitting with the USRP2. Both use a gr.head block and run to 
> completion after they have proccessed a certain ammount of samples.

The run() function on a top block is a wrapper around calls to start()
and wait().  The flowgraph will operate either until it exits on it's
own or until it is terminated by a signal (like ctrl-c).  The calling
thread context is blocked waiting for the internal wait() call to
return.  This is the typical way to run flowgraphs that don't need to do
anything else in the calling thread context.

You can retain control of the calling thread context by instead doing
this manually.

Calling start() on a top block creates a running thread per block (among
many other things), then returns to the calling context. You are free
then to do anything else needed in your application, and the GNU Radio
flowgraph runs "in the background."  This is how you would run control
code in Python that talks to the flowgraph through some mechanism like
messaging or function calls on individual blocks.

To end the flowgraph at some point, you call stop(), which sends an
interrupt to each of the GNU Radio block threads.  Finally, you call
wait(), which internally joins all the interrupted threads, so that when
wait() returns, all the flowgraph threads are known to have completed.

> I did some testing and it seems to work fine. But still I would like
>  to know if the following lines of Code make any sense:

In your case, since you are using head blocks, the flowgraph will exit
on its own when the requested number of samples have passed through the
head block.  However, you are trying to coordinate the activity of two
separate top blocks.  If you called run() on the first one, it would not
return from that call until the flowgraph exited, and your second
flowgraph would get started too late.

The first way to solve this is to call start() on each top block, then
call wait() each of them sequentially.  Thus, the two flowgraphs operate
simultaneously, and each one "exits" when its head block is done.  The
calls to wait() will ensure that your application while loop does not
continue until this happens.

The second (and better) way to do this is to put both signal processing
chains into one flowgraph.  Convert each of them to a hierarchical block
with no inputs or outputs, then create a top block, and use the
tb.connect() method:

tb = gr.top_block()
receiver = receiver_class() # now a hierarchical block with no I/O
transmitter = transmitter_class() # also a hierarchical block

tb.connect(receiver)
tb.connect(transmitter)

while (1):
tb.start() # starts threads
# Do stuff while the flowgraph is running (if needed)
tb.wait() # blocks until both hier blocks are in done state
# Do stuff in between flowgraph runs (if needed)

In your particular case, since you are using head blocks in both chains,
you could use run() in the loop instead of start() and wait(). The
flowgraph would finish naturally and run() would return.  This would not
let you, however, do anything while the flowgraph was running.

Finally, if you ever change the flowgraph such that it "runs forever"
instead of exiting on its own, you'd need to have a call to tb.stop() in
there at the point your control logic needs to shut things down.

Hope this makes things clearer.

-- 
Johnathan Corgan, Corgan Labs
SDR Training and Development Services
http://corganlabs.com
<>

signature.asc
Description: OpenPGP digital signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Dynamically set sample rate

[rmsrms1987]

Does anybody have any ideas on this question?



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Dynamically-set-sample-rate-tp44048p44128.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

Re: [Discuss-gnuradio] Dynamically set sample rate

[Marcus Leech]

Most sources/sinks have something like a set_sample_rate() method that can be called.
It's often useful to put together a flow-graph in GRC to see how this is organized in Python.
 
For example, if you change sample-rate on the fly, your downstream blocks that care about sample-rate are going to need to know, and "do the right thing".
 
 
on Oct 11, 2013, rmsrms1987  wrote:
Does anybody have any ideas on this question?--View this message in context: http://gnuradio.4.n7.nabble.com/Dynamically-set-sample-rate-tp44048p44128.htmlSent from the GnuRadio mailing list archive at Nabble.com.___Discuss-gnuradio mailing listDiscuss-gnuradio@gnu.orghttps://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] Dynamically set sample rate

[West, Nathan]

On Fri, Oct 11, 2013 at 12:36 PM, rmsrms1987  wrote:

> Does anybody have any ideas on this question?
>
>
>
> --
> View this message in context:
> http://gnuradio.4.n7.nabble.com/Dynamically-set-sample-rate-tp44048p44128.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>


http://gnuradio.org/doc/doxygen/page_uhd.html
Have you tried uhd.usrp_source.set_samp_rate()? I've never tried it in a
running flowgraph, but that sounds like what you want. Alternatively that
same page has another solution where you create a software resampler on
your host, which you can change the resampling ratio from.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GnuRadio flowgraphs in workerthread

[Alex3371]

Wow, thank you for your detailed answer. 

But one thing I don't understand:

" If you called run() on the first one, it would not 
return from that call until the flowgraph exited, and your second 
flowgraph would get started too late. "

I don't want the flowgraphs to run parallel to each other. One flowgraph
senses the spectrum with the USRP and the second flowgraph transmitts a
signal with the same USRP (depending on the measurements of the spectrum).
So it's important that they run consecutively. 

In this case, is it fine the way I do call run() for both flowgraphs? Would
replacing it with start() + wait() make any difference?

Also, I hope you don't mind if I add one more questions:

When the flowgraph is stopped by a head-block the threads are shutdown, but
the flowgraph itself still exists with all the blockinternal member
variables (including possible changes during the first run) and after a
head-reset it can be re-run with the run()-method. This re-run starts where
the previous run stopped. Is that correct?













--
View this message in context: 
http://gnuradio.4.n7.nabble.com/GnuRadio-flowgraphs-in-workerthread-tp44121p44131.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

Re: [Discuss-gnuradio] GnuRadio flowgraphs in workerthread

[Johnathan Corgan]

On 10/11/2013 11:48 AM, Alex3371 wrote:
> Wow, thank you for your detailed answer.
> 
> But one thing I don't understand:
> 
> " If you called run() on the first one, it would not return from that
> call until the flowgraph exited, and your second flowgraph would get
> started too late. "
> 
> I don't want the flowgraphs to run parallel to each other. One
> flowgraph senses the spectrum with the USRP and the second flowgraph
> transmitts a signal with the same USRP (depending on the measurements
> of the spectrum). So it's important that they run consecutively.

Ah, I missed this.

> In this case, is it fine the way I do call run() for both flowgraphs?
> Would replacing it with start() + wait() make any difference?

Since you have a finite length flowgraph, there really is no difference.

> When the flowgraph is stopped by a head-block the threads are
> shutdown, but the flowgraph itself still exists with all the
> blockinternal member variables (including possible changes during the
> first run) and after a head-reset it can be re-run with the
> run()-method. This re-run starts where the previous run stopped. Is
> that correct?

Yes.  On occasion we've found bugs in blocks that assumed their start()
functions would only get called once (like in the ALSA audio
source/sinks) but otherwise this is how it works.

I would suggest, however, that you reconsider this approach if you are
eventually going to be doing anything more than simple processing.
Starting and stopping flowgraphs is using a very heavy hammer and takes
a long time (in sample terms).

Instead, think of always having the two flowgraphs instatiated and
started, and adding a message input port to a custom block on the
transmitter and message output port to a custom block on the receiver.

You can then move your control logic into a Python message only block
that receives a message from the receiver, does whatever needs to be
done as a result of this, then triggers the transmitter by sending a
message to it.

The flowgraph then is always running, but you've separated your signal
processing control from flowgraph run/start/stop/wait semantics.

You can also extend this idea of a control block to allow triggering the
receiver (via message passing) from a GUI button, which can have an
event handler in the Python block to trigger the receiver via message.

(This description is missing details on how this would change your
flowgraphs to be message triggered, as I'm not aware of what's in them.)

Asynchronous messaging is a very new feature of GNU Radio and we don't
have many examples of using it to learn from.  But the above scenario is
one use case we had in mind in designing it.

-- 
Johnathan Corgan, Corgan Labs
SDR Training and Development Services
http://corganlabs.com
<>

signature.asc
Description: OpenPGP digital signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] QtGui in background or separate thread

[Victor User]

Hello,
 
I have a python program that does some signal processing on packets collected 
with the USRP and flowgraph.  Inside the constructor of my python class, I 
create an instance of my top-block object.  I'm trying to use the QtGui sink to 
display the spectrum while the processing is going on.  My constructor to my 
python class looks like:
 
def __init__(self, **kwargs):
internal variables 
self._tb= top_block_ctor( **args )
self._tb.start()
self._tb.qapp.exec_()
 
 
My problem is the blocking that occurs with the qapp.exec_().  If I remove that 
line in my constructor, then my processing works fine (without the display).  
If I leave that line, then my spectrum display works, but I don't start the 
processing until I close the display.  I know that this is what the 'blocking' 
should do. 
 
However, I would like it to not block or somehow run in another thread so that 
the display is "live" while the processing is going on.
 
Is there a way to do this? I could not fine any examples on-line.
 
Thanks___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] What conditions will cause block destructor to be skipped?

[Monahan-Mitchell, Tim]

Rarely, I'm seeing evidence that my custom source block destructor is not being 
called.

My flowgraph was built with "No GUI" and "Prompt for Exit" options (GR 3.7.1+)

The condition is that my source block's work function has moved to a state 
returning WORK_DONE, and will stay in that state.

When I press Enter to end the flowgraph, I sometimes don't see the usual ending 
printf() outputs. Fortunately, it does not happen often.

This article cites such a case: 
http://lists.gnu.org/archive/html/discuss-gnuradio/2013-02/msg00055.html, but 
my flowgraph only has my custom source block and a File Sink block.

Regards,
Tim

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

[Discuss-gnuradio] gnuradio 3.4.2 and /usr/bin/ld: cannot find -laudio

[Javier Ricke]

im trying of compile gnuradio 3.4.2 and dont work
My S.O is ubuntu 12.04 LTS 32 bits

and this error is:
"read -pthread   -pthread -Wl,-soname -Wl,libgnuradio-qtgui-3.4.2.so.0 -o
.libs/libgnuradio-qtgui-3.4.2.so.0.0.0
/usr/bin/ld: cannot find -laudio
collect2: ld returned 1 exit status
make[5]: *** [libgnuradio-qtgui.la] Error 1
make[5]: se sale del directorio «/home/javier/gnuradio-3.4.2/gr-qtgui/lib»
make[4]: *** [all] Error 2"

i dont understand and i read enough but i can't to resolve this problem

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

Re: [Discuss-gnuradio] Time synchronization between two USRPs without external signal

[Miklos Maroti]

Hi Harrz,

What do you mean by 160us precision? How did you measure it or compute
it exactly? I do not understand your goal, but it is quite simple to
synchronize two usrps with continuous transmission to within one
sample and if you continuously receive the transmitted signal on the
transmitter side, then you can avoid all time stamping problems and
effectively synchronize the tx and rx chains of a single usrp.

Miklos

On Thu, Oct 10, 2013 at 3:51 PM, Harry Zhang  wrote:
> Hi,
> I have implemented time synchronization between two USRPs without GPSDO,
> MIMO cable or referring to computer's time.It's a sender-receiver method
> based on message exchange. It will be included in my next paper soon.
> I use the tx_time and tx_sob tag to transmit the message at the planned
> time. When this message researches the receiver, I can get the receive
> time via rx_time tags. The transmit and receive time of tx tags and rx
> tags are recorded in USRP motherboard without the jitter of Ethernet
> cable or operating system. So I think it could achieve the best accuracy
> without modifying FPGA.
> The experiment shows the accuracy is around 160us. I think it's mostly
> caused by the jitter of the tx tag's time. I wanna achieve better
> accuracy than this and the best way is adding a hardware timestamp
> module in FPGA. Is this way feasible?
> As for now, I wanna get a depth understanding of the implementing of tx
> tag,so I will know the accuracy limit of this method. But I'm not
> familiar with the FPGA, so could anyone describe how tx_time tag
> implemented or give me some documents about this?
> Thanks in advance.
>
> ___
> 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] why the code in gnuradio in 3.6 cannot work in 3.7?

[Yingjie Chen]

Thanks for your reply, Martin. I have read the website about the change
before. But still nothing change when I run benchmark example in terminal,
even though I delete some original code in C++ block(for test). That means
my added code cannot take effect. Do I miss something?

Best,
Kay


2013/10/11 Martin Braun (CEL) 

> Read http://gnuradio.org/redmine/projects/gnuradio/wiki/Move_3-6_to_3-7
>
> MB
>
> On Fri, Oct 11, 2013 at 09:25:53PM +0800, Yingjie Chen wrote:
> > Hi guy,
> >
> >
> > I have updated the gunradio to 3.7.1, but fond the c++ block name and
> style
> > changed a litter bit. like ofdm_insert_preamble.cc is changed to
> > ofdm_instert_preamble_impl.cc. When I add some codes in general work
> funciton,
> > and use the command make and make install it in build directory as usual
> in
> > gnuradio 3.6, I cannot see any change after adding my personal code. I
> guess
> > the build fire is not installed. what is happening in 3.7?
> >
> >
> > Any help would be appreciated.
> >
> >
> > Best,
> >
> > Kay
> >
>
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> --
> 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
>
> ___
> 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