[Discuss-gnuradio] Extracting tags from gr-zeromq blocks directly in python with pmt.deserialize
Hello everyone, is there a way to use pmt.serialize(pmt_t obj, std::streambuf sink) and especially pmt.deserialize(std::streambuf source) in Python? Or is there another recommended way how to extract the serialized data from the zeromq messages? See documentation here http://gnuradio.org/doc/sphinx-3.7.0/pmt/serialize.html We need it here in order to extract the tags send from a zeromq pub sink block directly in Python with the zeromq.probe_manager We did some crazy kind of reverse engineering of the serialization format in order to be able to manually extract the data using pmt.deserialize_str(string str) But that is not generic (just works for the tags of the USRP block) at all and will probably break in a new version or so. Regards Johannes ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] phase shift block
Hi, Application Note Synchronization and MIMO Capability with USRP Devices from Ettus includes a phase_shift block in Figure 5. Whatever happend to that block? Can't find it, did it get replaced? Regards Johannes ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] PMT Python Bug
When I go to pmt and back to Python with a dict ints are converted to
long. Is that on purpose?
import pmt
a = {'asdf': 34, 'qwer': 3.7}
In [26]: pmt.to_python(pmt.to_pmt(a))
Out[26]: {'asdf': 34L, 'qwer': 3.7}
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gr_delay behaviour
One short question. What happens if I call the set_delay method of the gr_delay block during runtime. Will it throw away/add some samples when the delay is changed? I am actually trying to create a block that throws away some samples whenever I call a memberfunction skip() but having difficulties testing it. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr_delay behaviour
I am now just using a simple gr_block to asynchronously skip some samples from time to time by calling consume_each(d_skip_size); return 0; I didn't define any forecast function and it seems to work fine but I am wondering what is the performance impact of not doing this. Shouldn't I basically somehow let the scheduler know that I am skipping something by writinga custom forecast? The amount of skipped samples is relatively low compared to the passed samples. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP 1 and 2 Fuse replacement
Hi guys, we need to replace a Fuse in two USRP 1 and one USRP2 box. Can anybody tell me exactly which fuses we have to order? Regards Johannes Schmitz ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP 1 and 2 Fuse replacement
We are located in Germany. Here in Farnell I can only find PANASONIC ERBRE4R00V would it be ok as well? For USRP2 I can find COOPER BUSSMANN - TR/3216FF4-R - FUSE, SMD, 4A, 1206, FAST ACTING so this should be fine. They broke over a longer period of time, mostly due to broken power supplies. But weren't replaced because we didn't need all of our USRP's for quite some time. For the USRP1, the fuse is: ERB-SE4R00U Available at digikey And for USRP2: TR/3216FF4-R Both available at DigiKey But I have to ask--how did you blow fuses on 3 of your devices? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP 1 and 2 Fuse replacement
Ok we just decided to order from DigiKey and take the parts that you have mentioned. For the USRP1, the fuse is: ERB-SE4R00U Available at digikey And for USRP2: TR/3216FF4-R Both available at DigiKey ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP transient peak from lock, unlock, set decim/freq
Also, there's no reason to lock the flow-graph for frequency changes or gain changes (or a bunch of other parametric changes within the flow-graph). I've never had to use lock()/unlock()--I understand that they're used during flow-graph topology changes. But parametric changes don't require lock()/unlock() at all. Actually I am using lock and unlock for flowgraph reconfiguration during runtime. I found a way how to avoid transient problems. I will just reset my filters some time after it occurs. Now I found another similar problem. I saw this somewhere before but forgot that it occurs: When I stop my receiver and transmitter and then look at usrp_fft I can still see a very strong and small peak at the carrier frequency. How can I avoid/remove this? Regards, Johannes ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP transient peak from lock, unlock, set decim/freq
I am getting some kind of very strong transient peak when using lock
unlock and changing usrp decimation rate and frequency and in the
beginning.
Is this a normal behaviour?
So each time I reconfigure my system I have to throw away some samples
to avoid this peak or am I doing something wrong?
I made this short example program and the peak can be found at the
beginning of the logged data and somewhere in the middle. The
beginning peak only occurs sometimes. So make sure to run it several
times if you want to see it.
It happens in USRP1 as well as USRP2.
I hope somebody can confirm this or tell me that the problem has been
removed in newer gnuradio versions.
Johannes
#!/usr/bin/env python
from gnuradio import gr
from gnuradio import usrp
from gnuradio import usrp2
from gr_tools import log_to_file
from time import sleep
class top_block(gr.top_block):
def __init__(self):
gr.top_block.__init__(self, fusb error)
self.u = usrp.source_c ()
#self.u = usrp2.source_32fc('eth1')
self.sink = gr.null_sink(gr.sizeof_gr_complex)
self.connect(self.u, self.sink)
log_to_file(self, self.u, data/test_u.compl)
def reconfigure(self):
self.lock()
sleep(1)
print 'lock'
self.unlock()
print 'unlock'
if __name__ == '__main__':
app = top_block()
app.start()
sleep(1)
print 'start'
app.reconfigure()
print reconfigured
sleep(1)
print 'now stopping'
app.stop()
print 'stopped'
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] c++ probe block concurrency, locking necessary?
Hi Johnathan,
can you give me some hint how to use the mutex? Why is it not possible
just to use lock and unlock?
Regards,
Johannes
2011/7/8 Johannes Schmitz jsem...@gmx.de:
I changed my code to use boost::mutex now. Therefore I included
#include boost/thread.hpp
Then I did something like this, which made my program go into a deadlock :(
in header:
boost::mutex d_metric_mutex;
in .cc
d_metric_mutex.lock();
d_metric.x = 1
d_metric.y = 2
d_metric_mutex.unlock();
and accessor:
metric get_metric ()
{
d_metric_mutex.lock();
return d_metric;
d_metric_mutex.unlock();
}
2011/7/8 Johannes Schmitz jsem...@gmx.de:
Thanks for your answer.
Yes, this is not only possible but likely to happen. You will need to
acquire a mutex in your work function just prior to updating the probe data,
and release it afterward. The accessor function also needs to do the same,
copy the probe data locally, then release the mutex. The gruel library in
GNU Radio is has a gruel::mutex for this purpose. It's really a typedef for
boost::mutex, so you can also use that directly.
I am really kind of a beginner when it comes to this mutex stuff.
Since we don't have the newest gnuradio version from git running here
it seems I need to use something called mld_mutex instead of gruel.
I found this via google in usrp/host/lib/fusb_darwin but it is not
working. I couldn't find out which header to include.
My idea was to do something like this:
d_metric is a struct
d_metric_mutex-lock();
d_metric.x = something
d_metric.y = something
d_metric_mutex-unlock();
metric get_metric () const
{
d_metric_mutex-lock();
return d_metric;
d_metric_mutex-unlock();
}
So when I return a struct to python via SWIG, what will happen. Will
there be some copy of it generated?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] c++ probe block concurrency, locking necessary?
Hey guys,
I am implementing a probe block that stores several values to a member
struct so they can be read from pyhton via accessor method
(get_probe_values() const {return probe_struct;}).
Now my question is: Is it necessary to use some kind of thread locking
mechanism to prevent gnuradio from changing one of the values until
the accessor method can return the whole struct to python?
I am affraid of getting probe values from different cycles that
don't belong together.
In other words is it possible that the work() method and
get_probe_values() will be called at the same time and I get some
concurrency problem?
Johannes
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] c++ probe block concurrency, locking necessary?
Thanks for your answer.
Yes, this is not only possible but likely to happen. You will need to
acquire a mutex in your work function just prior to updating the probe data,
and release it afterward. The accessor function also needs to do the same,
copy the probe data locally, then release the mutex. The gruel library in
GNU Radio is has a gruel::mutex for this purpose. It's really a typedef for
boost::mutex, so you can also use that directly.
I am really kind of a beginner when it comes to this mutex stuff.
Since we don't have the newest gnuradio version from git running here
it seems I need to use something called mld_mutex instead of gruel.
I found this via google in usrp/host/lib/fusb_darwin but it is not
working. I couldn't find out which header to include.
My idea was to do something like this:
d_metric is a struct
d_metric_mutex-lock();
d_metric.x = something
d_metric.y = something
d_metric_mutex-unlock();
metric get_metric () const
{
d_metric_mutex-lock();
return d_metric;
d_metric_mutex-unlock();
}
So when I return a struct to python via SWIG, what will happen. Will
there be some copy of it generated?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] c++ probe block concurrency, locking necessary?
I changed my code to use boost::mutex now. Therefore I included
#include boost/thread.hpp
Then I did something like this, which made my program go into a deadlock :(
in header:
boost::mutex d_metric_mutex;
in .cc
d_metric_mutex.lock();
d_metric.x = 1
d_metric.y = 2
d_metric_mutex.unlock();
and accessor:
metric get_metric ()
{
d_metric_mutex.lock();
return d_metric;
d_metric_mutex.unlock();
}
2011/7/8 Johannes Schmitz jsem...@gmx.de:
Thanks for your answer.
Yes, this is not only possible but likely to happen. You will need to
acquire a mutex in your work function just prior to updating the probe data,
and release it afterward. The accessor function also needs to do the same,
copy the probe data locally, then release the mutex. The gruel library in
GNU Radio is has a gruel::mutex for this purpose. It's really a typedef for
boost::mutex, so you can also use that directly.
I am really kind of a beginner when it comes to this mutex stuff.
Since we don't have the newest gnuradio version from git running here
it seems I need to use something called mld_mutex instead of gruel.
I found this via google in usrp/host/lib/fusb_darwin but it is not
working. I couldn't find out which header to include.
My idea was to do something like this:
d_metric is a struct
d_metric_mutex-lock();
d_metric.x = something
d_metric.y = something
d_metric_mutex-unlock();
metric get_metric () const
{
d_metric_mutex-lock();
return d_metric;
d_metric_mutex-unlock();
}
So when I return a struct to python via SWIG, what will happen. Will
there be some copy of it generated?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] solving u0u0 problems
Hi Marcus, What type of sample rates? What compute platform? We are running on Ubuntu 10.10 64bit. What do you mean with type of sample rates? Maybe USRP decimation rate? I am changing fft-size based on this. So for 4MHz i am using 1088 fft-size and for 2MHz i am using 544MHz and I am getting the problem when running with 2MHz. FFTW performance is often counter-intuitive. Can you explain this? Are you using the default TPB scheduling? What is TPB scheduling? How can I find out more about scheduling? I never found something like this in the documentation. What else is in your flow-graph? First block is a stream to vector conversion. Then I am doing a number of operations on this vectors using standard GNUradio blocks as well as some custom made blocks. I still don't know what this u0u0 means and from which part of GNUradio it comes from. Is suppose it is some kind of buffer overflow between the blocks or something like that? Regards, Johannes ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] solving u0u0 problems
I mean what sample rates--it sounds like 2Msps and 4Msps. You are right. If you haven't touched it, then you're using TPB (Thread Per Block) scheduling. What other schedulers are available? Where can I find information about this? uO means USRP overrun--the USRP is delivering data at a rate that is faster than your flow-graph can keep up with, causing overruns. OK. The only way to cure this is to reduce your sample rates, reduce your flow-graph computational complexity, or use a higher-performance computer. The strange thing is the problem occurs when I am reducing the sampling rate. So how can find out which block in my flowgraph is running to slow? -Johannes ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] solving u0u0 problems
Hey Marcus, I used oprofile to get a better idea where the problem is located. I found that it is indeed a problem with libfftw3. Besides the gnuradio fft block I am calculating a crosscorrelation using the fft. That means fft-size will be 2*N-1 with vectorlength N. So for 1024 vectorlength I will be calculating an fft of size 2047. Maybe this is the problem. Now my idea is to pad the fft input to a power of 2 size or use a cyclic cross correlation instead. Any other suggestions? Johannes ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 General I/O
I guess there's a search function for a reason; I have found a similar question in the archives and I believe I have found a suitable answer. Sorry for the waste of time. Then why dont you post the link to the answer in here? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] solving u0u0 problems
Hi Marcus, Tom Rondeau, on the mailing list, is the guy to talk to about adding new blocks. There is a correlator block already. Ok, maybe I will contact Tom. Which block do you mean exactly? I am looking for a block that acts like xcorr() in matlab. There is no such block. I refer to sample-rate matching. For example, audio devices often run at a sample rate of 44.1Ksps, which is obviously different than the sample rate you're using in your flow-graph. So if your flow-graph ends up (for example) sending output to an audio sink, the sample stream has to be decimated or interpolated to the rate of the audio sink. Sometimes, people forget this when using the audio sinks, and get into the types of trouble you're observing. I am not doing something like this. We are working with USRP's. By the way I was able to fix the initial problem using a cyclic cross correlation function with power of 2 fft-size. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] how to remove/suppress gr_buffer::allocate_buffer: warning:
I am getting the following warning when running my script: gr_buffer::allocate_buffer: warning: tried to allocate 4 items of size 88192. Due to alignment requirements 32 were allocated. If this isn't OK, consider padding your structure to a power-of-two bytes. On this platform, our allocation granularity is 4096 bytes. Can somebody tell me how to solve this problem or suppress this warning? I found it has to do something with fft-size that is not power of 2.. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] how to remove/suppress gr_buffer::allocate_buffer: warning:
Hello Martin, I will check my code to find out why it is so big. Is there an easy way to somehow suppress this warning in case I am willing to ignore it? Johannes 2011/6/17 Martin Braun martin.br...@kit.edu: On Fri, Jun 17, 2011 at 03:42:07PM +0200, Johannes Schmitz wrote: I am getting the following warning when running my script: gr_buffer::allocate_buffer: warning: tried to allocate 4 items of size 88192. Due to alignment requirements 32 were allocated. If this isn't OK, consider padding your structure to a power-of-two bytes. On this platform, our allocation granularity is 4096 bytes. Can somebody tell me how to solve this problem or suppress this warning? I found it has to do something with fft-size that is not power of 2.. Buffers between blocks are always an integer multiple of the item-size (in your case 88192) and 4096. The LCM of 88192 and 4096 is pretty large, and tadaa, you get a warning. It's just a warning. If everything works fine... just ignore it. But it's a waste of memory. If you want to optimize this, change your itemsize. You will normally have to adapt the way the data is handled, e.g., you could pad the input to 90112=22*4096 and then discard 90112-88192=1920 Bytes of every input vector. Personally, I usually just ignore it, since it rarely turns up in less unusual applications. MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] fusb: (rd status -2) No such file or directory
Is it conceivable that this particular problem is specific to a particular type of USB host controller, since various folks have reported I can't make it break, whereas a couple of folks (Johannes and Brett) are able to make it break. We tried with two different PCs and two IBM Notebooks. It happens every time. So I am not sure if we can say that it is because of host controller type. Maybe it is an Ubuntu specific problem. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] fusb: (rd status -2) No such file or directory
Hello Thomas, I'm not able to reproduce this error with the posted examples. Please try compiling with the --fusb-tech=libusb1 option and post any error output. It may not solve the problem, but debugging with libusb is simpler than debugging through the kernel. Which distribution are you using? Is it Ubuntu as well? I tried to compile with this option but I am getting the following error when running configure: checking for boost = 1.35... no configure: error: we could not detect the boost libraries (version 1.35 or higher). If you are sure you have boost installed, then check your version number looking in boost/version.hpp. boost 1.42 is installed so I don't understand this. Johannes ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] how to trigger dynamic reconfiguration with lock/disconnect
Hello Yang, Do you have any specific questions? Better you write some example programs first, then come back with your exact questions I think. Johannes ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] fusb: (rd status -2) No such file or directory
You gotta be more specific. IBM Notebooks doesn't tell us what USB controller it is. At least give us the output of lspci. Actually our two Lab PC seem to have the same USB Controller: 00:1d.0 USB Controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller But I tried on another machine which has nvidia MCP61 USB Controller The IBM Notebook (T61) has a Intel 82801H Controller. USRP Revision is 4.2 (at least the one I have on my desktop) -Johannes ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] fusb: (rd status -2) No such file or directory
I found that our gnuradio is based on a version from git from Thu Feb 11 08:18:46 2010 But there are some patches and changes from our side so it is not so easy for us to just jump to the newest version Today I compiled the newest version from git to see what happens with the example code and I don't get the fusb problem anymore. Does anybody know which patch resolved the issue? Johannes ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] fusb: (rd status -2) No such file or directory
In your gnuradio generated code you use run() instead of start() method and you forgot to put unlock(). After changing this it crashes with fusb error. 2011/5/27 Brett L. Trotter b...@webtrotter.com: Does this crash you? from gnuradio import eng_notation from gnuradio import gr from gnuradio.eng_option import eng_option from gnuradio.gr import firdes from grc_gnuradio import usrp as grc_usrp from optparse import OptionParser class crashme(gr.top_block): def __init__(self): gr.top_block.__init__(self, Crashme) ## # Variables ## self.interp = interp = 64 self.decim = decim = 32 self.tx_rate = tx_rate = 128e6/interp self.rx_rate = rx_rate = 64e6/decim self.center_freq = center_freq = 1e6 ## # Blocks ## self.usrp_simple_source_x_0 = grc_usrp.simple_source_c(which=0, side=A, rx_ant=RXAB) self.usrp_simple_source_x_0.set_decim_rate(decim) self.usrp_simple_source_x_0.set_frequency(center_freq, verbose=True) self.usrp_simple_source_x_0.set_gain(0) self.usrp_simple_sink_x_0 = grc_usrp.simple_sink_c(which=0, side=A) self.usrp_simple_sink_x_0.set_interp_rate(interp) self.usrp_simple_sink_x_0.set_frequency(center_freq, verbose=True) self.usrp_simple_sink_x_0.set_gain(0) self.gr_sig_source_x_0 = gr.sig_source_c(tx_rate, gr.GR_SIN_WAVE, 1000, 4000, 0) self.gr_null_sink_0 = gr.null_sink(gr.sizeof_gr_complex*1) self.gr_head_0_0 = gr.head(gr.sizeof_gr_complex*1, 300) self.gr_head_0 = gr.head(gr.sizeof_gr_complex*1, 300) ## # Connections ## self.connect((self.gr_sig_source_x_0, 0), (self.gr_head_0, 0)) self.connect((self.gr_head_0, 0), (self.usrp_simple_sink_x_0, 0)) self.connect((self.usrp_simple_source_x_0, 0), (self.gr_head_0_0, 0)) self.connect((self.gr_head_0_0, 0), (self.gr_null_sink_0, 0)) if __name__ == '__main__': parser = OptionParser(option_class=eng_option, usage=%prog: [options]) (options, args) = parser.parse_args() tb = crashme() tb.run() print Flowgraph finished, calling lock tb.lock() print Calling stop tb.stop() ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] fusb: (rd status -2) No such file or directory
The error is coming from the kernel. Can you describe your system setup? We tried to run the code on Ubuntu 10.04, 10.10 and 11.04. Every time we get the fusb error :( It seems we have to throw away our USRP1's and move to USRP2... Johannes ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] fusb: (rd status -2) No such file or directory
Hello Marcus, Have you tried it under UHD? we did not try it under UHD. Honestly I don't have any experience with UHD. But do you want to say that the traditional API is not supported anymore? If yes, what is the best way to get started with UHD? Johannes ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] fusb: (rd status -2) No such file or directory
Hello Brett, please use Reply All when answering, or send it only to the mailinglist. But don't send it only to me. Of course I inserted unlock somewhere after lock. Also you have to replace tb.run() with tb.start(). Johannes 2011/5/30 Brett L. Trotter b...@webtrotter.com: On 05/30/2011 07:13 AM, Johannes Schmitz wrote: In your gnuradio generated code you use run() instead of start() method and you forgot to put unlock(). After changing this it crashes with fusb error. most of that was actually generated by GRC, I only added a few lines: print Flowgraph finished, calling lock tb.lock() print Calling stop tb.stop() Where did you insert unlock()? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] how to trigger dynamic reconfiguration with lock/disconnect
Hello Alex, What documentation was possible to find? Was this part of it: http://gnuradio.org/redmine/wiki/gnuradio/TutorialsWritePythonApplications#Controlling-flow-graphs In this document disconnect is not mentioned at all. Your example and another example from the mailing list helped me to understand how to basically use it. In some post I found an example which shows that the system gets stuck if you use lock/unlock in a hierarchical block. see this: http://www.mail-archive.com/discuss-gnuradio@gnu.org/msg18108.html (The hang is a different bug that will be addressed soon.) and that was 2009 but for me the code still hangs. So I am planning to create two hierarchical blocks and switch between them at the top block layer. The problem now is I have no idea how to trigger the reconfiguration based on some events that occur in the hierarchical blocks. I need to send a message/control signal to the top block to tell him to lock and reconfigure but I don't know how to do this. Regards, Johannes ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] how to trigger dynamic reconfiguration with lock/disconnect
I did some more research on the topic to get some ideas. Now it seems there are two possibilities to send control signals between the blocks: 1. Use a message queue and a watcher thread like in the digital example pkt.py 2. Use a probe block like gr.probe_avg_mag_sqrd and an endless while loop in the main that checks for a change in some bool variable in this block Can anybody confirm this or tell me some other possibilities? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] how to trigger dynamic reconfiguration with lock/disconnect
Hi Scott, This works well during testing. Once you get some kind of protocol or some series of steps that you want to do, you can just test a flag, and whenever your block finishes set it to true, then reconfigure. What do you mean with your block finishes ? How do you implement this flags? I am now using a thread to implement the state machine. I am using member variables in the C++ blocks to implement the flags or to hand over certain signals/values to the control thread. Johannes ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] fusb: (rd status -2) No such file or directory
I am getting this error: fusb: (rd status -2) No such file or directory What does it mean and what can I do to solve this. Crazy thing is it doesn't happen every time I call my rx script. I tried to pull usrp power plug and usb plug but it did not help. Johannes ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] fusb: (rd status -2) No such file or directory
I made a simple example to show how it happens. It is a problem of lock/unlock in combination with usrp. Like this the lock unlock disconnect seems to absolutely unusable :( - #!/usr/bin/env python from gnuradio import gr from gnuradio import usrp from time import sleep class top_block(gr.top_block): def __init__(self): gr.top_block.__init__(self, fusb error) self.u = usrp.source_c () self.sink = gr.null_sink(gr.sizeof_gr_complex) self.connect(self.u, self.sink) def reconfigure(self): self.lock() print 'lock' self.unlock() print 'unlock' if __name__ == '__main__': app = top_block() app.start() #sleep(1) print 'start' app.reconfigure() print reconfigured sleep(1) print 'now stopping' app.stop() print 'stopped' ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] fusb: (rd status -2) No such file or directory
We are running Ubuntu 10.10, I can not look up the kernel version because I am at home right now but it should be 2.6.35-28. Do you need further details? Johannes ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Reconfigure example with lock/disconnect/connect/unlock code hangs randomly
Hey guys, I have written some example code to learn how to dynamically reconfigure gnuradio based on events generated by probe blocks and a watcher thread. First I thought everything is running very well but later I noticed that the program hangs if you let it run long enough. If you uncomment the sleep(0.0001) it seems to be working fine but says: Exception in thread Thread-1 (most likely raised during interpreter shutdown) We are running Ubuntu 10.10 over here. Can somebody please run the code and confirm this? Looks like a bug for me. --- #!/usr/bin/env python from gnuradio import gr import gnuradio.gr.gr_threading as _threading from time import sleep class h_block_one(gr.hier_block2): def __init__(self): gr.hier_block2.__init__(self, foo, gr.io_signature(0, 0, 0), gr.io_signature(0, 0, 0)) vec = range(100) self.source = gr.vector_source_f(vec,True,1) self.probe = gr.probe_signal_f() self.sink = gr.null_sink(gr.sizeof_float) self.connect(self.source, self.probe) def level_one(self): return self.probe.level() class h_block_two(gr.hier_block2): def __init__(self): gr.hier_block2.__init__(self, bar, gr.io_signature(0, 0, 0), gr.io_signature(0, 0, 0)) vec = range(100) self.source = gr.vector_source_f(vec,True,1) self.probe = gr.probe_signal_f() self.sink = gr.null_sink(gr.sizeof_float) self.connect(self.source, self.probe) def level_two(self): return self.probe.level() class probe_this(gr.top_block): def __init__(self): gr.top_block.__init__(self, 'Probe Reconfigure Test') self.h_block_one = h_block_one() self.h_block_two = h_block_two() self.connect(self.h_block_one) def level_one(self): return self.h_block_one.level_one() def level_two(self): return self.h_block_two.level_two() def reconfigure(self): self.lock() self.disconnect(self.h_block_one) self.connect(self.h_block_two) self.unlock() def conf_back(self): self.lock() self.disconnect(self.h_block_two) self.connect(self.h_block_one) #sleep(0.0001) self.unlock() class _probe_watcher_thread(_threading.Thread): def __init__(self, level_one, reconfigure, level_two, conf_back): _threading.Thread.__init__(self) self.setDaemon(1) self.level_one = level_one self.reconfigure = reconfigure self.level_two = level_two self.conf_back = conf_back self.confed = False self.keep_running = True self.start() def run(self): while self.keep_running: if self.confed: if self.level_two() 50: self.conf_back() self.confed = False print 'reconfiguring' else: if self.level_one() 50: self.reconfigure() self.confed = True print 'reconfiguring back' #if self.level_one and self.level_two: #print 'foo', self.level_one() #print 'bar', self.level_two() if __name__==__main__: def callback(msg): print 'received:', msg tb = probe_this() watcher = _probe_watcher_thread(tb.level_one,tb.reconfigure,tb.level_two,tb.conf_back) tb.start() sleep(100) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Reconfigure example with lock/disconnect/connect/unlock code hangs randomly
There should be another sleep in the reconfigure method to make it working fine. def reconfigure(self): self.lock() self.disconnect(self.h_block_one) self.connect(self.h_block_two) sleep(0.0001) self.unlock() I am not sure how long we have to sleep in order to fix the problem. - Johannes ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] how to trigger dynamic reconfiguration with lock/disconnect
Hello Guys, I am working on a cognitive radio application and I need to dynamically reconfigure my receiver, switching between a detector and the core receiver. I found lock, unlock, connect, disconnect functions but it seems to be almost impossible to find some documentation or a working examples to understand how to use it. I need to find a way to trigger the disconnect and connect. Do you have any suggestions like some kind of callback? Maybe you can point me to some example code. That would be nice. Another question is: Is it possible to reconnect only parts of the program in some hierarchical block or is it only possible from the top block? Regards, Johannes ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
