Re: [Discuss-gnuradio] Problems passing the control between blocks - message passing
Hi John,
I wrote the code in C++ based on UHD_AMsg_source.cc, provided in GRExtras.
In my work function, I've finished it using return -1 (ie. the block has
finished processing correctly) as shown below:
int work(
const InputItems &,
const OutputItems &
){
//work definition here (ie. generate a packet and post downstream)
return -1; //done running, work done status
}
However, in that way the block in GNU Radio Companion runs only once. The
other possibility is not to use "return" at all, but in that case what I
have is:
1. BLOCK 1 generates a packet
2. BLOCK 1 post the packet downstream
Step 1 and 2 repeats "N times". When finishes, it gives the control to
BLOCK 2 to process the message. However, I need a sequence as follows:
1. BLOCK 1 generates a packet
2. BLOCK 1 post the packet downstream
3. BLOCK 2 process the packet
4. BLOCK 2 post the message again downstream and so on...
Step 1 to 4 should repeat "N times".
Thanks again for your help,
Jose
On Wed, Oct 17, 2012 at 4:52 PM, John Malsbury wrote:
> Jose,
>
> Try a while(1) with a block and a blocking call to pop msg's off the
> queue:
>
> self.pop_msg_queue()
>
> Should help you avoid the return -1
>
> Or maybe I've misunderstood your problem...?
>
> -John
>
>
>
> On Tue, Oct 16, 2012 at 11:18 PM, Jose Torres Diaz <
> torresdiaz.j...@gmail.com> wrote:
>
>> Hi All,
>>
>> I'm working with 2 blocks that I've created using "UHD_AMsg_Source" as a
>> reference model. In these blocks, I am passing pmt_dict type as messages,
>> ie:
>>
>> this->post_msg(0, AMSG_KEY, dictionary,_id);
>>
>> Where, dictionary contains data/metadata that I can read in the next
>> block downstream.
>>
>> BLOCK 1 -- (pmt_dict included in the message) --> BLOCK 2
>>
>> The blocks are working ok, but the problem is that when I want to
>> generate several packets and post them downstream, BLOCK 1 runs until
>> finishes and then BLOCK 2 takes the control until finishes. The problem is
>> the "return" sentence in my work function. I did 2 possible ways
>>
>> Option 1: Using -1
>>
>> work {
>> //work here
>> return -1
>> }
>>
>> In this way BLOCK 1 stops working after one iteration and it does not run
>> as many times as I want.
>>
>> Option 1: Not using return
>>
>> work {
>> //work here
>> }
>>
>> In this way BLOCK 1 runs many times and posts messages downstream all
>> those times, but it gives the control to BLOCK 2 when it finishes. Then,
>> BLOCK 2 takes the messages from the message queue. However, this
>> implementation is not useful for me. BLOCK 1 should post a message
>> downstream and then, BLOCK 2 takes the message and work with the packet.
>>
>> Any suggestion is welcome, thanks a lot for your time,
>>
>> Regards,
>>
>> Jose
>>
>> ___
>> 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] Problems passing the control between blocks - message passing
Hi All,
I'm working with 2 blocks that I've created using "UHD_AMsg_Source" as a
reference model. In these blocks, I am passing pmt_dict type as messages,
ie:
this->post_msg(0, AMSG_KEY, dictionary,_id);
Where, dictionary contains data/metadata that I can read in the next block
downstream.
BLOCK 1 -- (pmt_dict included in the message) --> BLOCK 2
The blocks are working ok, but the problem is that when I want to generate
several packets and post them downstream, BLOCK 1 runs until finishes and
then BLOCK 2 takes the control until finishes. The problem is the "return"
sentence in my work function. I did 2 possible ways
Option 1: Using -1
work {
//work here
return -1
}
In this way BLOCK 1 stops working after one iteration and it does not run
as many times as I want.
Option 1: Not using return
work {
//work here
}
In this way BLOCK 1 runs many times and posts messages downstream all those
times, but it gives the control to BLOCK 2 when it finishes. Then, BLOCK 2
takes the messages from the message queue. However, this implementation is
not useful for me. BLOCK 1 should post a message downstream and then, BLOCK
2 takes the message and work with the packet.
Any suggestion is welcome, thanks a lot for your time,
Regards,
Jose
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Running older USRP scripts with GNURadio 3.60
Hello, I have ubuntu 12.04 and GNURadio 3.6.2. I was trying to run some older scripts which uses the USRP. These scripts were made with GNURadio Companion about 3 years ago, and then I added some extra menu options by manually editing the python script made by GRC. Unfortunately when I run the scripts, I get a "can't find USRP" type error. I understand in the newer GNURadio installations that USRP is replaced with UHD. Does anyone know of an easy way to run older scripts that call the USRP class? I am not experienced enough to convert all the old scripts. I would likely have to make new ones with the newer GNURadio Companion installation and add all the extra menu features again manually. Thank you, Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cannot make new signal processing block
On Tue, Oct 16, 2012 at 5:08 AM, nexy_sm wrote: > Of course, that's at least what I can do. > > First of all, I would like to say that the biggest problem was lack of my > knowledge in Linux. > I was strictly following instructions from gnuradio.org about making out of > tree signal processing block, and there is not stated that i have to do > /make install/ before testing module. > Also, nowhere is stated stest -V, for getting more error information, and > also using -DCMAKE_INSTALL_PREFIX, whish is used for setting base address or > whatever. > > Maybe somebody should make detailed tutorials, for the people that knows > only signal processing, not Linux, just for smooth start, unti they get > used. > > Regards > Nemanja Unfortunately, you cannot separate the signal processing of SDR from the operating system. You need to understand a bit of each if you're going to do anything really, truly useful. So while you're struggling to get some of this stuff started, you are also learning a lot about Linux and the build tools. This will serve you immeasurably well in the future. I am right now struggling through similar issues with OSX. That having been said, we are slowly producing more information to help people out. Look at the Doxygen manual that get's generated when you install GNU Radio. There's a lot more information in there to help people understand some features of GNU Radio and of the build system. The -V 'trick' for ctest is kind of outside of the scope of GNU Radio. That's something that's documented with ctest. I learned about this myself by just searching for help on getting information out of 'make test.' One of the biggest problems we can have as developers is that we are probably the worst people to document the code, especially features like what you are talking about. It's hard to know what others don't know. A lot of what is on the instructions and manuals that I've put in are because I was just learning something, like using cmake properly, and thought, "oh, this is something that should be documented." We have to rely on people to help us put this together. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Wireless Camera Reception?
On Mon, Oct 15, 2012 at 6:26 PM, Joel Mayer wrote: > ** > Dear GNUradio enthusiasts- > > Beneath these lines (attached as a virus free pdf) you will find a table > of frequencies > assigned to wireless cameras. I'm wondering, would it be possible to > modify the SDR# > radio in such a way as to make it wireless camera capable? > > Thanks For Reading This! > Joel, I don't know about SDR# since this is the GNU Radio mailing list. But yes, in principle GNU Radio could be made to work with these. You'd need a system that can handle the bandwidth, so you'd be looking at a USRP N200 with the appropriate daughterboard. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cannot make new signal processing block
On Tue, Oct 16, 2012 at 03:14:31AM -0700, nexy_sm wrote:
> Do you mean some kind of tutorial or what?
>
> Well, that means that my test don't work, since you said that make install
> isn't necesary.
>
> So, let's start again, what might be a problem?
That's still impossible to tell from what you've written.
I've just checked that gr_modtool and the tutorial are correct.
Here's what I did:
1) Create an out-of-tree module
~/tmp % gr_modtool.py create test
Module directory is "./gr-test".
Creating directory...
Copying howto example...
Unpacking...
Replacing occurences of 'howto' to 'test'... Done.
Use 'gr_modtool add' to add a new block to this currently empty module.
2) Then, I add a sync-block:
~/tmp% cd gr-test
tmp/gr-test % gr_modtool.py add -t sync square_ff
Operating in directory .
GNU Radio module name identified: test
Code is of type: sync
Block/code identifier: square_ff
Enter valid argument list, including default arguments:
Add Python QA code? [Y/n]
Add C++ QA code? [Y/n] n
Traversing lib...
Adding file 'square_ff_impl.h'...
Adding file 'square_ff_impl.cc'...
Adding file 'square_ff.h'...
Traversing swig...
Editing swig/test_swig.i...
Traversing python...
Adding file 'qa_square_ff.py'...
Editing python/CMakeLists.txt...
Traversing grc...
Adding file 'test_square_ff.xml'...
Editing grc/CMakeLists.txt...
3) Next, I edit the work() function of the block (this only needs one
line to be changed) to look like this:
Before this is done, the 'make' command won't work!
{
const float *in = (const float *) input_items[0];
float *out = (float *) output_items[0];
for (int i = 0; i < noutput_items; i++) {
out[i] = in[i] * in[i];
}
// Tell runtime system how many output items we produced.
return noutput_items;
}
4) Finally, I edit the file python/qa_square_ff.py such that the test case
contains this:
Before this is done, the 'make test' or 'ctest' commands won't work!
def test_001_t (self):
test_data = (1, 2, 3, 4)
correct_res = (1, 4, 9, 16)
sink = gr.vector_sink_f()
self.tb.connect(gr.vector_source_f(test_data), test.square_ff(), sink)
self.tb.run()
self.assertEqual(sink.data(), correct_res)
Then, I go to the build directory and invoke the make process:
gr-test/build % cmake .. # Output omitted
gr-test/build % make # Output omitted
gr-test/build % make test
Running tests...
Test project /home/braun/tmp/gr-test/build
Start 1: test_test
1/2 Test #1: test_test Passed0.02 sec
Start 2: qa_square_ff
2/2 Test #2: qa_square_ff . Passed0.23 sec
100% tests passed, 0 tests failed out of 2
The End.
This entire process took me less than 10 minutes. If you're taking
longer, you're wasting time.
Other notes:
* I never installed
* The only editing necessary was three lines in the work() function and the
test case in qa_square_ff
So go through your module once again, start from scratch and it will
work.
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
pgpmsiC526W4K.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cannot make new signal processing block
Do you mean some kind of tutorial or what? Well, that means that my test don't work, since you said that make install isn't necesary. So, let's start again, what might be a problem? -- View this message in context: http://gnuradio.4.n7.nabble.com/cannot-make-new-signal-processing-block-tp37924p38021.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] cannot make new signal processing block
On Tue, Oct 16, 2012 at 02:08:42AM -0700, nexy_sm wrote: > First of all, I would like to say that the biggest problem was lack of my > knowledge in Linux. > I was strictly following instructions from gnuradio.org about making out of > tree signal processing block, and there is not stated that i have to do > /make install/ before testing module. Hm, you shouldn't need to do that. (That's why it's not in the instructions.) > Also, nowhere is stated stest -V, for getting more error information, and > also using -DCMAKE_INSTALL_PREFIX, whish is used for setting base address or > whatever. That's already what I'd consider 'advanced' usage, which is why it's not in the tutorial, either. Although I guess 'ctest -V' could be in there. > Maybe somebody should make detailed tutorials, for the people that knows > only signal processing, not Linux, just for smooth start, unti they get > used. Since you just went through the process, how about writing something while the knowledge is still fresh? 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 pgpkBe9KSW79M.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cannot make new signal processing block
Of course, that's at least what I can do. First of all, I would like to say that the biggest problem was lack of my knowledge in Linux. I was strictly following instructions from gnuradio.org about making out of tree signal processing block, and there is not stated that i have to do /make install/ before testing module. Also, nowhere is stated stest -V, for getting more error information, and also using -DCMAKE_INSTALL_PREFIX, whish is used for setting base address or whatever. Maybe somebody should make detailed tutorials, for the people that knows only signal processing, not Linux, just for smooth start, unti they get used. Regards Nemanja -- View this message in context: http://gnuradio.4.n7.nabble.com/cannot-make-new-signal-processing-block-tp37924p38019.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] Discuss-gnuradio Digest, Vol 119, Issue 15 (Usrp_nbfm_ptt.py)
On Tue, Oct 16, 2012 at 01:14:30AM -0700, Sajjad Safdar wrote: > Yes i can see that i hve errors because of the red marks, but i first want to > know that whether i have all the control stuff in my reciever as from > usrp_nbfm_ptt.py or should i have to add some more stuff which is not exactly > translated into my GRC. Sajjad, are you saying you want to know whether or not your flow graph will work once you fix the error messages? I'd guess yes. Just try it! 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 pgpp96Ul8haRY.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
