Re: [Discuss-gnuradio] setting hw number
> > > Hi All, > > I'm unable to get simple_ra to recognize the USRP1. > I have carried out the check below but do not know how to set the 'hw > number' in 'simple_ra' > > Hope someone is able to help. > > Many thanks, > > Frank > --- > alpha@alpha:~$ cat /proc/asound/cards > 0 [Intel ]: HDA-Intel - HDA Intel > HDA Intel at 0xfdff8000 irq 44 > alpha@alpha:~$ > > -- > > alpha@alpha:~$ aplay --list-devices > List of PLAYBACK Hardware Devices > card 0: Intel [HDA Intel], device 0: VT2020 Analog [VT2020 Analog] > Subdevices: 1/1 > Subdevice #0: subdevice #0 > card 0: Intel [HDA Intel], device 2: VT2020 HP [VT2020 HP] > Subdevices: 1/1 > Subdevice #0: subdevice #0 > Hi Frank, you are checking for Audio devices, the USRP is a regular USB device, not an audio device. You can see information about your USRP hardware with uhd_find_devices, given you use the UHD to interface your USRP. Try to find out if simple_ra also works with other devices than sound cards. Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Detecting EOF of previous block
Dear list, I have another question regarding stopping the flowgraph. This time it is about streaming blocks, no messages involved at all. My flowgraph looks like this (block A) --byte--> (block B) --byte--> ... Block A is a byte source that signals EOF at a certain point, lets assume after sending out 11 bytes. Block B is a ratio 1:1 sync block which works on groups of input items, say 5 bytes. If B's work is provided with less than 5 samples it will return 0 and wait to get more samples. Unfortunatley the blocksize of block B is not fixed but based on a state, so I can't call set_output_multiple to tell the scheduler to only provide me with multiples of 5 bytes because a few items later it might change to 6 bytes. As you can see from the example above B will process the first 10 bytes like expected, but then there is still one byte left to be processed by B. The problem I have is to detect whether block B is asked to process only one byte, because that's all the scheduler has so far (but A will produce more), or if it is asked to process this one sample because that is the last one available (A has already signaled EOF). Is there any build in way to detect that the previous block in the flowgraph has already signaled EOF? The only way I could think of is to attach an EOF stream tag to the stream in the previous block A and evaluate the tags in block B. Are there any other approaches/ideas? Might a general EOF tag be a good idea for gnuradio (so that file source and head or even the scheduler itself attach the EOF tag)? Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Usage of Message Queues
> Im sorry that im pushing my question, but its still unsolved for me and > need > it for my project.. > > So again, my message queue is filling, i checked that via > tb.sink_queue.count(), but if i want to transfer pop a message, it just > returns me that message_sptr thing. Can someone help me on that? I cant > find > a proper manual how to use the message queues/sinks. > > Again, thanks in advance for any hints :). > > > > -- > View this message in context: > http://gnuradio.4.n7.nabble.com/Usage-of-Message-Queues-tp39295p39455.html > Sent from the GnuRadio mailing list archive at Nabble.com. Hi, I don't know much about messages and it's queues from the python side, but maybe a hint to the C++ side will help you to continue. It appears that the object you get back is a wrapped shared pointer. So basically a pointer to a gr_message which's C++ interface is documented here: http://gnuradio.org/doc/doxygen/classgr__message.html In C++ you can use the shared pointer like a usual pointer to that class so I guess that's the same in gnuradio. Just try if you can get the length of the message with returned_var.length() Usually with the msg() member you return an unsigned char pointer to the actual data of the message. My best guess would be that this is wrapped to a list of numpy's uint8 values. I hope that makes it possible for you to continue. Another possible source might be the QA code for gr_msg_source and gr_msg_sink (if there is any) which should deal with messages in python. Yours Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] make test hangs at gr-core-test-all qa_pdu
> On Tue, Feb 5, 2013 at 12:42 PM, "Martin Lülf" wrote: > >> > On Tue, Feb 5, 2013 at 5:28 AM, "Martin Lülf" wrote: >> > >> >> Hi, >> >> >> >> while working on my issue with asynchronous blocks ( >> >> >> https://lists.gnu.org/archive/html/discuss-gnuradio/2013-01/msg00488.html >> >> ). I discovered that the two tests 'gr-core-test-all' and 'qa_pdu' >> >> sometimes hang up. That means they never return until I interrupt >> with >> >> Ctr+C. If I repeat the same make test without changing anything in >> >> between, the tests sometimes run through and sometimes hang up again. >> >> >> >> I am running Ubuntu 12.04.2 LTS (GNU/Linux 3.2.0-35-generic x86_64) >> with >> >> the gnuradio master branch. >> >> >> >> Yours >> >> Martin Luelf >> >> >> > >> > What version of Boost are you running? If it's 1.46, 1.47, or 1.52, >> that >> > would explain the gr-core-test-all. It's a bug in Boost that we get >> hit >> > with (and we're supposed to not link against those versions, but >> > apparently >> > haven't done that right; see Issue #513). >> > >> > The PDU hangup I think is a race condition. I thought that I had fixed >> > that, but apparently not entirely. I just opened up Issue 514 about >> this. >> > >> > Thanks for reporting. >> > >> > Tom >> > >> >> Hi Tom, >> >> thank you for your fast reply. Indeed updating to a newer version of >> boost >> (I moved from 1.46 to 1.53) seems to fix both of the issues. I repeated >> make test for 10 times and both tests (as well as all others) ran >> through >> without issues every time. Before I hat to retry only once or twice to >> get >> a hangup. >> >> However I am still curious to learn how flowgraph start/stop works for >> asynchronous blocks, as they don't have a start/stop function, as far as >> I >> understood. Can you point me to some documentation or a certain piece of >> code where I can learn more about this? >> >> Yours >> Martin > > > I'm not sure what you mean by asynchronous blocks? All blocks run as > threads. We can join them and interrupt them (all our threads are started > with a Boost interruption point for this). > > Tom > Hi Tom, by asynchronous blocks I mean a block that has only message ports as in and outputs and thus no general_work function. As far as I saw these block's start()/stop() functions are not called even if I implement them. So when does such a block start or how/when is it stopped again? Especially regarding such a block's start please also see my previous post to the mailing list https://lists.gnu.org/archive/html/discuss-gnuradio/2013-01/msg00488.html Yours Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] make test hangs at gr-core-test-all qa_pdu
> On Tue, Feb 5, 2013 at 5:28 AM, "Martin Lülf" wrote: > >> Hi, >> >> while working on my issue with asynchronous blocks ( >> https://lists.gnu.org/archive/html/discuss-gnuradio/2013-01/msg00488.html >> ). I discovered that the two tests 'gr-core-test-all' and 'qa_pdu' >> sometimes hang up. That means they never return until I interrupt with >> Ctr+C. If I repeat the same make test without changing anything in >> between, the tests sometimes run through and sometimes hang up again. >> >> I am running Ubuntu 12.04.2 LTS (GNU/Linux 3.2.0-35-generic x86_64) with >> the gnuradio master branch. >> >> Yours >> Martin Luelf >> > > What version of Boost are you running? If it's 1.46, 1.47, or 1.52, that > would explain the gr-core-test-all. It's a bug in Boost that we get hit > with (and we're supposed to not link against those versions, but > apparently > haven't done that right; see Issue #513). > > The PDU hangup I think is a race condition. I thought that I had fixed > that, but apparently not entirely. I just opened up Issue 514 about this. > > Thanks for reporting. > > Tom > Hi Tom, thank you for your fast reply. Indeed updating to a newer version of boost (I moved from 1.46 to 1.53) seems to fix both of the issues. I repeated make test for 10 times and both tests (as well as all others) ran through without issues every time. Before I hat to retry only once or twice to get a hangup. However I am still curious to learn how flowgraph start/stop works for asynchronous blocks, as they don't have a start/stop function, as far as I understood. Can you point me to some documentation or a certain piece of code where I can learn more about this? Yours Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem while doing make in making block
> On Sun, Feb 3, 2013 at 6:02 AM, Mohammed Ramadan > wrote: > >> >> i am still face problem for making simple block in gnuradio >> i am using gr_modtool >> i follow the steps >> 1- creating the module ( named ramadan) >> 2 adding the block(mm) >> i have 2 files in lib (mm_imp.cc, mm_imp.hh) and one file in include >> (mm.h) >> i made changes in the 3 files like square example in tutorial, but while >> building i face problem in make appears for me >> >> el-hadidy@ubuntu:~/gr-ramadan/build$ make >> Scanning dependencies of target gnuradio-ramadan >> [ 5%] Building CXX object >> lib/CMakeFiles/gnuradio-ramadan.dir/mm_impl.cc.o >> /home/el-hadidy/gr-ramadan/lib/mm_impl.cc:32:29: error: >> howto_square_ff.h: >> No such file or directory >> /home/el-hadidy/gr-ramadan/lib/mm_impl.cc:39: error: >> ?howto_square_ff_sptr? does not name a type >> /home/el-hadidy/gr-ramadan/lib/mm_impl.cc:62: error: ?howto_square_ff? >> has >> not been declared >> /home/el-hadidy/gr-ramadan/lib/mm_impl.cc:62: error: ISO C++ forbids >> declaration of ?howto_square_ff? with no type >> /home/el-hadidy/gr-ramadan/lib/mm_impl.cc: In function ?int >> howto_square_ff()?: >> /home/el-hadidy/gr-ramadan/lib/mm_impl.cc:63: error: only constructors >> take base initializers >> /home/el-hadidy/gr-ramadan/lib/mm_impl.cc: At global scope: >> /home/el-hadidy/gr-ramadan/lib/mm_impl.cc:73: error: expected >> constructor, >> destructor, or type conversion before ?::? token >> /home/el-hadidy/gr-ramadan/lib/mm_impl.cc:79: error: ?howto_square_ff? >> is >> not a class or namespace >> /home/el-hadidy/gr-ramadan/lib/mm_impl.cc: In function ?int >> general_work(int, gr_vector_int&, gr_vector_const_void_star&, >> gr_vector_void_star&)?: >> /home/el-hadidy/gr-ramadan/lib/mm_impl.cc:94: error: ?consume_each? was >> not declared in this scope >> *make[2]: *** [lib/CMakeFiles/gnuradio-ramadan.dir/mm_impl.cc.o] Error 1 >> make[1]: *** [lib/CMakeFiles/gnuradio-ramadan.dir/all] Error 2 >> make: *** [all] Error 2* >> el-hadidy@ubuntu:~/gr-ramadan/build$ >> >> so , how can i solve this problem? can any one help me to fix this >> problem >> as i read more and still face problems. Thanks > > > Again, this looks like a version problem. Except in this case, it looks > like you have a really old version of GNU Radio installed before there was > a consume_each (and I can't even remember how far back that was). > > Tom To me it looks like there are some classname:: missing in the implementation file, in which case the general_work is defined outside the class and thus undefined (at least that's when I am seeing these errors). Can you check/post your .cc code? Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] make test hangs at gr-core-test-all qa_pdu
Hi, while working on my issue with asynchronous blocks ( https://lists.gnu.org/archive/html/discuss-gnuradio/2013-01/msg00488.html ). I discovered that the two tests 'gr-core-test-all' and 'qa_pdu' sometimes hang up. That means they never return until I interrupt with Ctr+C. If I repeat the same make test without changing anything in between, the tests sometimes run through and sometimes hang up again. I am running Ubuntu 12.04.2 LTS (GNU/Linux 3.2.0-35-generic x86_64) with the gnuradio master branch. Yours Martin Luelf ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem loading Python block
> Guys, > > As i told you my new installation works fine, I eve tested blocks in > python. Now, the problem is following: > > I designed block in python which has None for both input and output > signature. I wanted to use such block only for receiving messages and for > writing to terminal some information, etc. > The constructor of my new block, is executed, but the problem is work > function is never executed. I put some printing at the beginning of work > function and nothing happens. The work function looks like this: > > > Could the problem be no inputs and no outputs? Or maybe something else? > > Best and thanks > > Nemanja > Hi Nemanja, the work function is called by the scheduler, which only calls the work function, if it has some samples to process. So if your block is not part of the flow graph (which it isn't since you have no input or output stream) it will not get called. You could either create a Thread in the block's constructor which will call the work function (the start/stop functions seem to not being called either), or you could try the new message passing interface, where you can register a callback function that is called whenever a new message arrives. Yours Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Detect start of flowgraph for asynchronous blocks
Hi list, I have been playing around with the new message passing interface, but was unable to detect the start of the flowgraph in my asynchronous block. The block has a worker thread that will request frames over the network and send them out over a message port. The worker thread is started in the constructor of my block like it is done in gr_message_strobe. This will however result in a race condition since the other side of the message queue might not have been constructed yet and as a consequence the first frames (messages) might be send out but not received by any block since these other blocks have not yet been subscribed to the output port. So basically I need a different way of starting my worker thread. Unfortunately the block's start() method does not get called, since my block is not part of the (stream) flowgraph. A work-around would be to give my block a stream input and connect it to a low-rate null source in order to make it receive the start/stop calls, but that's not elegant at all. What is the official way of creating a block that will generate asynchronous messages and wants to make sure that even the first message it sends out is received by the other blocks? Any suggestion or pointer into the right direction is appreciated. Yours Martin Luelf ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
