Re: Does complex conjugate invert IQ ?

[Martin Luelf]

Dear Rachida,

in order to do that, use the "complex to float" and "float to complex" 
blocks and connect the re output to the im input and the im output to 
the re input.


Yours
Martin


On 13.12.21 16:31, Rachida SAROUI wrote:
Thank you for responding, but what I meant by invert is swapping the I 
and Q components of the signal.


Le lun. 13 déc. 2021 à 16:25, Fabian Schwartau > a écrit :


Complex conjugate only inverts the imaginary (Q) part of the signal.
If you want to invert both, just multiply with -1.

Am 13.12.21 um 16:22 schrieb Rachida SAROUI:
 > Hi everyone,
 >
 > I need to invert the I and Q of a complex signal. Does the block
complex
 > conjugate do the job?
 >
 > Thank you
 >

Re: Questions On GNU Radio FFT Data logging

[Martin Luelf]

Dear Zen Chen,

to subscribe to the mailing list you need to follow this link: 
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

I think the account on the GNURadio website is for editing the Wiki etc.

You are sampling your signal at 10 MSamples per second. Since you use a 
complex signal (blue input to the file sink) that means each sample is 
two 32 bit floating point numbers). Thus your generated binary file has 
a size of 80 MByte per second of recording.


If you convert that into a CSV file the default formater for 
numpy.savetxt() is .18e, meaning that each real and imaginary part will 
be written as 24 characters (one place before the decimal, the decimal 
point, the 18 places after the decimal and 4 chars for the exponential). 
These need to be delimited by a comma and finally a new line character. 
That makes 50 characters per measurement. For a regular ASCII file each 
char is 1 Byte so you are writing 50 Byte/sample * 10 MSample/s = 500 
MByte per second of recording.


That is a lot of data. For a 5 second recording for example you are 
asking Excel to import a 5GB file (!). I don't know Excel too much but 
that sounds like it might be to much. Possible remedies are: try to 
reduce the sampling rate (which will reduce the monitored bandwidth) or 
try to record very short bursts, or (my personal opinion) try to analyze 
your signal in a program that is more suitable to signal analysis than 
Excel. You most definitely want something that can work directly with 
the binary files from GNURadio's file sink rather than having to use a 
CSV file. GNURadio itself, python/numpy, Matlab/octave, C++ are all good 
choices for the analysis (and certainly many more).


Yours
Martin



On 10.12.21 09:59, Zen Chen wrote:
Yes933_10_12_20212nd.csv 

HI all,My name is Zen Chen , a GNU radio Novice and I tried to create an 
account on the GNU Radio .org website to post my questions on the 
mailing list however I could not . I am using GNU radio and Hack RF 1 to 
design a power spectrum analyser and I am using the attached flowgraph 
to and python script to give me the attached CSV file however , the 
results (FFT connect to file sink) is to large to be contained in a 
single excel file . Is there a problem in my GNU Radio Flowgraph?


Regards,
Chong Zhi

Re: Adding custom function in OOT module

[Martin Luelf]

Dear Wei,
which GNURadio version are you using?

On 3.9 you need to update the python bindings for your block (assuming 
you have a python flowgraph).


Before 3.8 you need to make sure that the SWIG bindings that GNURadio 
generates are updated (which should happen automatically, but for me 
they get stuck sometimes). Try deleting the build folder and build your 
OOT again from scratch.


Yours
Martin


On 10.10.21 23:30, Huang Wei wrote:

Hi group,

It could be a simple question, but I could not find the solution. I am 
writing my own OOT C++ module, I want to add a function get_value() in 
the block, so I can use Function Probe to read value in the block 
through this function.

so in the lib/my_block_impl.cc, I added:
double my_block_impl::get_value()
{
    return value_global;
}
int my_block_impl::work(...)
{
    ...
}

in lib/my_block_impl.h, I added:
Public:
   double get_value() override;

and in include/tootl/my_block.h, I added:
Public:
   virtual double get_value() = 0;

Then I did: make, sudo make install and sudo ldconfig.
But when I run the flowgraph, it keeps saying that "my_block_sptr" 
object has no attribute "get_value". where I made the mistake?

Thank you very much for your help!

Regards,
Wei

Re: How to debug GNU Radio's C++ program from source code?

[Martin Luelf]

Hi,

in case you don't have VS code, you can also run GDB directly 
https://wiki.gnuradio.org/index.php/TutorialsDebugging#Tutorial:_Using_gdb_with_Pythonic_GR_applications


Yours
Martin


On 03/08/2021 15:48, Josh Morman wrote:

Hello!

Even though GNU Radio has python bindings with swig or pybind11, the 
underlying code c++ symbols are still accessible with GDB. Using Visual 
Studio Code and GNU Radio compiled from source with Debug Symbols this 
is pretty straightforward:

1) Open up the source tree of gnuradio in visual studio code
2) edit the launch.json and add a C++/GDB configuration where program is 
python and args is the output of the GRC rendering

         {
             "name": "(gdb) Launch",
             "type": "cppdbg",
             "request": "launch",
             "program": "/usr/bin/python3",
             "args": ["/path/to/grc_output.py"],
             "stopAtEntry": false,
             "cwd": "${workspaceFolder}",
             "environment": [],
             "externalConsole": false,
             "MIMode": "gdb",
             "setupCommands": [
                 {
                     "description": "Enable pretty-printing for gdb",
                     "text": "-enable-pretty-printing",
                     "ignoreFailures": true
                 }
             ]
         },
3) put the breakpoint where you want to hit - note that GR will have 
been compiled with optimizations, so the breakpoints might be a bit funky

4) F5 to run the application

If you are debugging your own OOT, this makes it even simpler because 
you can compile as "-DCMAKE_BUILD_TYPE=Debug" and then your breakpoints 
will be very predictable - in this case you just open up VS code from 
the root of your project and follow the same steps.


Hope this helps.

Josh



On Tue, Aug 3, 2021 at 8:41 AM 能书能言 <2127629...@qq.com 
> wrote:


Hi guys!
I want to know how to debug c++ code in gnuradio. As far as I know,
after we run GRC, a Python file will be generated. The Python file
connects various blocks, but if I debug this Python file directly, I
cannot observe the internal operations of the C++ block. I want to
know if there is any way to let me Can I see the contents of the
c++work function when I run the python file? It's like executing a
pure Python or pure C++ program.
If this is not possible because of the swig connection method, how
can I observe the work of a C++ block's work function? If I look at
the code directly, it is definitely not accurate enough. Can I write
a demo by myself? Or other ways.
In addition, how to edit an existing block? I just want to modify
its function slightly. Do I have to use gr_modtool to create a new
OOT module and rewrite it based on the contents of the original
block? You must also use debugging methods when writing, but I don't
know how to do it.
in addition. I have tried the tutorials on the official website, but
none of them worked. I also checked the previous mailing list, but
it was not very helpful. I think anyone has a better solution?
Sincerely

Re: Having problems using forecast method

[Martin Luelf]

1] (so now the output should be [0,1,4,5,8,9]). The QA test bombs and 
stated: handler caught exception: index 4 is out of bounds for axis 0 
which is size 4. I inserted some print statements inside 
the general_work method to see the values for ninput_items and 
noutput_items and the ninput_items was 12 (the size of the input vector 
in the QA test) and noutput_items was 4. noutput_items was 
4 explains why the program bombs because out[jj] with jj = 4 means I am 
attempting to place a value in out[4] which does not exist because 
noutput_items is 4. Based on the settings in the forecast method, I was 
expecting that if the scheduler set noutput_items to 4, then it would 
set ninput_items to 4*M/N = 8 and the program would not bomb, it would 
work perfectly. Then in the next scheduler round, the last 4 samples 
would be brought in for processing.


Any ideas on how I can fix the simple program above so I can use the 
forecast method and get it to work?


Thanks again for your help.
George



On Tue, Jul 6, 2021 at 1:04 AM Martin Luelf <mailto:m...@mluelf.de>> wrote:


Dear George,

what specifically does not work with your test? Any error messages, or
is it not producing the result you are expecting. And if so, what is
your block input, what is the output and what output are you expecting?

Keep in mind that the forecast method tells the scheduler how much
input
you *likely* need. This is not binding, meaning the general_work method
does not have to produce this number of outputs, nor does GNURadio have
to give you that exact amount of input data. In the general_work method
you need to tell the scheduler how many samples you used (using the
consume method) and how many samples you created (by returning that
number).

Also be aware of the data types in C++. noutput_items is an int. If M
and N are integer types as well, C++ will round M/N to the nearest
integer before multiplying it to noutput_items and you have effectively
created an integer decimating block. To avoid that you want to cast
M, N
and noutput_items to a floating point number type (if you know the C++
specifics you can probably get away with just casting one type and have
the compiler cast the others, but just to be sure I would cast them all
to float). With that you will get a floating point number of samples
that your block needs. Since GNURadio can only deal with an integer
number of samples, it is up to you and your algorithm to bring that
to a
sensible integer number. Most likely you will want to round that number
up or down and feed this integer number of samples back into
ninput_items_required[0].

Yours
Martin


On 05.07.21 22:51, George Edwards wrote:
 > Hello,
 >
 > I played with it and got it to work. I left out the forecast
method and
 > forced my will on the scheduler in terms of the input to output
 > sample relationship.
 >
 > However, I am still open to hearing from anyone who has used the
general
 > block with the forecast method to solve this problem, so as to
have the
 > perspective on how to use the forecast method.
 >
 > Thanks!
 >
 > George
 >
 > On Mon, Jul 5, 2021 at 2:44 PM George Edwards
mailto:gedwards@gmail.com>
 > <mailto:gedwards@gmail.com <mailto:gedwards@gmail.com>>>
wrote:
 >
 >     Good afternoon GNURadio community!
 >
 >     I am having a problem using the forecast method in my OOT model.
 >
 >     In my model, I have one input port and one output port with
 >     streaming data. My signal processing algorithm converts every M
 >     input samples into N output samples where the ratio of M to N
is a
 >     floating point number, soI cannot use the sync  block (if
M=N) nor
 >     the interpolator or decimator OOT blocks.
 >
 >     I am forced to use the general or basic block which has
theforecast
 >     method where one has to inform the Scheduler of the relationship
 >     between the input and output samples.
 >
 >     In the forecast method, I set up the relationship as:
 >     ninput_items_required[i] = noutput_items*M/N
 >     which is the precise relationship. However, on running the QA
test I
 >     cannot get the OOT module to work properly.
 >
 >     Will appreciate any suggestions!
 >
 >     Regards,
 >     George
 >

Re: Having problems using forecast method

[Martin Luelf]

Dear George,

what specifically does not work with your test? Any error messages, or 
is it not producing the result you are expecting. And if so, what is 
your block input, what is the output and what output are you expecting?


Keep in mind that the forecast method tells the scheduler how much input 
you *likely* need. This is not binding, meaning the general_work method 
does not have to produce this number of outputs, nor does GNURadio have 
to give you that exact amount of input data. In the general_work method 
you need to tell the scheduler how many samples you used (using the 
consume method) and how many samples you created (by returning that number).


Also be aware of the data types in C++. noutput_items is an int. If M 
and N are integer types as well, C++ will round M/N to the nearest 
integer before multiplying it to noutput_items and you have effectively 
created an integer decimating block. To avoid that you want to cast M, N 
and noutput_items to a floating point number type (if you know the C++ 
specifics you can probably get away with just casting one type and have 
the compiler cast the others, but just to be sure I would cast them all 
to float). With that you will get a floating point number of samples 
that your block needs. Since GNURadio can only deal with an integer 
number of samples, it is up to you and your algorithm to bring that to a 
sensible integer number. Most likely you will want to round that number 
up or down and feed this integer number of samples back into 
ninput_items_required[0].


Yours
Martin


On 05.07.21 22:51, George Edwards wrote:

Hello,

I played with it and got it to work. I left out the forecast method and 
forced my will on the scheduler in terms of the input to output 
sample relationship.


However, I am still open to hearing from anyone who has used the general 
block with the forecast method to solve this problem, so as to have the 
perspective on how to use the forecast method.


Thanks!

George

On Mon, Jul 5, 2021 at 2:44 PM George Edwards > wrote:


Good afternoon GNURadio community!

I am having a problem using the forecast method in my OOT model.

In my model, I have one input port and one output port with
streaming data. My signal processing algorithm converts every M
input samples into N output samples where the ratio of M to N is a
floating point number, soI cannot use the sync  block (if M=N) nor
the interpolator or decimator OOT blocks.

I am forced to use the general or basic block which has theforecast
method where one has to inform the Scheduler of the relationship
between the input and output samples.

In the forecast method, I set up the relationship as:
ninput_items_required[i] = noutput_items*M/N
which is the precise relationship. However, on running the QA test I
cannot get the OOT module to work properly.

Will appreciate any suggestions!

Regards,
George

Re: How to print Socket PDU messages on the terminal?

[Martin Luelf]

Hi Shumin,

netcat (nc) uses TCP by default, but your Socket PDU is set to UDP. So 
you are sending and listening to two different sockets.


There are two ways to fix that (but don't apply both at the same time or 
it won't work again):
1. Switch the PDU Socket type to TCP Server (like it is done it the 
reference you linked).
2. Use the command "nc -u 127.0.0.1 52001" where the -u option will make 
netcat use UDP instead.


Yours
Martin

On 09.12.20 09:47, Shumin Yao wrote:

Hi,

I am working on a straightforward project. In the project, there is a 
Vector Source transmits a vector to a Socket PDU module. I am trying to 
print the vector received by the Socket PDU module on the terminal but 
fail to do that.


My settings are as follows. The transmitted vector is full of "1"s. The 
host of the Socket PDU module is set to "127.0.0.1", and the port of the 
Socket PDU module is set to "52001".


On the terminal window, I type a command "nc 127.0.0.1 52001" (according 
to Section 3 in [1]) but obtain nothing.


Am I missing something?

Note: the screenshot of my flowgraph is attached.

[1] http://joshuaedgcombe.com/getting-started-with-gnu-radio/

Thank you for reading this mail,

Shumin Yao.

Sending out messages on block shutdown

[Martin Luelf]

Dear list,

I have a custom frame sync block that takes a stream of complex samples 
as inputs (output signature is 0,0) and outputs PDU messages if frames 
were found. When the upstream block is done I would still like to send 
out a few messages (flushing an internal buffer), before shutting down 
the block and signaling the subscribed block that we are done.


With GNURadio 3.7 I sent out these messages in the stop() method 
followed by an PMT EOF object, which worked great.


Now I finally ported my block to 3.8 and noticed that the messages send 
out during the stop() call are no longer received by the subscribed block.


Is there a way to find out that the call to the work function is going 
to be the last call, or is there another way of learning that the block 
is being stopped at a time where the subscribed block is still listening 
for messages?


Yours
Martin

Re: Having trouble with C++ OOT block in restricting output to those input values I wish to pass

[Martin Luelf]

Hi George,

noutput_items is a number given to you by GNURadio. I would not 
overwrite this variable, otherwise you no longer know how many items you 
can write into the output buffer. Create a new variable nitems_written 
or similar to track how many items you have written.


Also have a look at what each variable is tracking exactly. cnt seems to 
be the number of input bytes you have checked for the preamble. But you 
also use it to compute the position in the out array, which does not 
make sense to me. cnt would increase with more spurious bytes in front 
of the preamble, but the output position should not depend on the number 
of spurious bytes. From the code you showed me cnt also seems to persist 
between multiple calls to general_work, but the out array is always 
clean when general_work is called again (meaning that on every 
general_work call you should always start writing to element 0).


You loop over your entire input array and if the preamble was found you 
copy the entire preamble and then you copy every following byte one by 
one. That means you copy the entire preamble again (without the first 
byte) and if your input buffer is longer than your message size you also 
copy more bytes to the output than your message is long which could 
result in missing the next preamble. Also you are potentially writing 
more items into the out array than GNURadio has space for, which is why 
I recommend you not to overwrite noutput_items and while you are still 
learning check that your computed indices for out and in are within the 
allowed bounds before every single write and read (i.e. by using 
assertions).


What messages are you using in your unittest and what kind of spurious 
bytes? Is is all zeros, or all ones? I would recommend you use different 
bytes, e.g. an increasing counter for your message and a decreasing 
counter starting from 255 for your spurious bytes so you can quickly 
spot if your messages are cropped, or off in some other way. Because the 
way you describe your results it seems like one message is copied twice. 
I could not find any obvious bug in your code that would output a 
message exactly twice, so I suppose it copies some data that look like a 
message on the first glance.


Yours
Martin


On 11.09.20 03:06, George Edwards wrote:

Hi Martin,

Thanks for your detailed answer. I really appreciate the great effort 
you put into explaining how things work. I am still on the learning curve.


I used your suggestions to the best of my understanding and it worked 
beautifully for the one sync pattern test vector in the QA test.


Then, I took your suggestion for repeated sync patterns using an init 
flag which I reset to 0 to restart the process. For the QA test, I 
repeated the original input data twice (now I have 2 sync patterns), so 
the expected QA output should be the original output repeated twice. I 
modified the C code by adding an if statement at the end to check if 
noutput_items == Buf_size+message_size (buf_size is the length of the 
pattern, which I call preamble) and if it is, I reset the init flag to 
zero as well as other params used in the initialization section of the 
code. The QA test failed by producing an output with 3 repeated copies 
of the original output rather than the expected 2 copies. I do not 
expect you to send too much time looking at my code below, however, I 
would appreciate it very much, if you would glance at it to see if you 
can spot what I am doing wrong. The test to un-initialize (setting init 
to 0) was done towards the end of the code block after the consume method.


       int kk = 0;

   for (int i = 0; i < ninput_items[0]; i++)

   {

  if(!init){__

     cnt += 1;   // cnt number of passing bytes

     kk = initialize(in[i]);

     if (kk == 0){

     noutput_items =  cnt;

     }else{

     memcpy((void*)out, (const void*)preamble, buf_size);

     noutput_items = cnt;

     }

  } else {

    out[i-cnt+buf_size] = in[i];

    noutput_items = buf_size + message_size;

  }

   } 

   consume_each (noutput_items);

   if (noutput_items == buf_size + message_size){

  init = 0;  // re-initialize all

  cnt = 0;

  kk = 0;

   }

   return noutput_items;

     }


Thanks very much for the help.

Regards,
George

On Thu, Sep 10, 2020 at 12:06 AM Martin Luelf <mailto:m...@mluelf.de>> wrote:


Dear George,

this also caused me a lot of headache when I started with GNURadio, so
here is what I learned about it.

Let's start with the forecast method. This tells GNURadio how many
input
samples you need on each input stream to generate the requested number
of output items. Usually GNURadio will run your forecast function a
cou

Re: Having trouble with C++ OOT block in restricting output to those input values I wish to pass

[Martin Luelf]

Dear George,

this also caused me a lot of headache when I started with GNURadio, so 
here is what I learned about it.


Let's start with the forecast method. This tells GNURadio how many input 
samples you need on each input stream to generate the requested number 
of output items. Usually GNURadio will run your forecast function a 
couple of times with different output numbers to find a good data chunk 
size to give to the general work function. Keep in mind that the number 
of required input items you give here is a minimum number and GNURadio 
might decide to give you more input data than you requested. It is also 
important to know that the number of samples you request here is just an 
estimate. You are not forced to actually process that much data.


Now to the general_work function. noutput_items tells you how many 
samples GNURadio would like you to produce (this is a maximum number you 
may produce less). It also tells you how much memory is allocated in 
every array in the output_items vector. If you have only one output and 
you used the default  *out = ( *) output_items[0]; 
definition this tells you how many items you can place (at most) into 
the out array.


The ninput_items[] array tells you how many input items are available in 
the input arrays. Again if you just have one input and you use const type> *in = (const  *) input_items[0]; ninput_items[0] is the 
number of inputs available in the in array. You may not read more items 
than that from the array.


Within the given input symbols you can start looking for your sync 
pattern. If you generate output you have to write (in your case copy) it 
to the out array. At the end of general_work you call consume(0, K) with 
the number of input items K that you have consumed on input 0. That is 
how many of the input items you have used and do not need to see again. 
If you consume 0 symbols the next call to general_work will show you the 
exact same input samples again. If you consume ninput_items[0] you will 
see completely new input samples on the first input the next time 
general_work is called. And then you return the number of samples you 
generated (i.e. how much samples you put into the out array). This 
number must be smaller or equal noutput_items, because otherwise you 
would have written out of the allocated memory which might result in a 
segfault/core dump. Note that you don't have to call consume at the very 
end of work and there is also another way of telling GNURadio how many 
samples you have produced, but let's leave that for another day.


So a very easy (but not the most efficient) setup for your problem could be:
Add a boolean flag to your _impl class that both forecast and 
general_work can read/write to. This flag will indicate whether or not 
you have found the sync pattern or not. You initialize this flag with false.
Assume you have a sync pattern of length L and a message with M data 
symbols afterwards.


In forecast if the flag is set (meaning you have found the sync pattern) 
you need L+M symbols of input. If the flag is not set you need L input 
samples, regardless of how many output samples GNURadio wants you to 
generate.


In general work if the flag is false you search the input for the sync 
pattern. If you found it at position i (counting from 0) you set the 
flag to true, consume i samples (i.e. everything before the sync 
marker). If the sync marker is not found you keep the flag to false and 
consume the inputs that you have searched so far. In both cases you 
return 0 since you have not generated any output yet.


If the flag is true you copy the first L+M samples from the input to the 
output, you set the flag to false (because after the data you have to 
start searching for the sync marker again) you consume L+M samples and 
return L+M samples.


Note: This is a very easy to understand scheme, but unfortunately not 
very efficient. You only process a single block of either unwanted 
spurious symbols, or one sync marker and data at a time. So once you 
have a good understanding of how this works you should tweak that block 
to be able to process multiple blocks of spurious symbols and sync 
patterns/data within once call to general_work. It uses the same kind of 
logic, but requires more housekeeping of counters and indices.


If your input is symbols rather than bits/bytes you should also look at 
the paper from J. Massey "Optimum Frame Synchronization" from 1972 on 
how to perform optimum sync marker detection, which performs better than 
the intuitive correlation search.


Hope that gets you started.

Yours
Martin


On 10.09.20 04:34, George Edwards wrote:

Hello,

I am writing an OOT block in C++ that receives a sequence of numbers and 
searches through for a sync pattern and passes to its output the sync 
pattern and the  bytes of data which follows it. The QA test shows the 
block recognizes the pattern and will pass the pattern along with the 
data that follow it, but there is a problem. The 

Re: GNU Radio 3.7 on Ubuntu 20.04

[Martin Luelf]

Hi,

I just updated my Kubuntu today without thinking about GNURadio (and due 
to my OOT not being ported to 3.8 yet I am still stuck on 3.7). I still 
have python2 running like a charm. But I could not get the QT bindings 
running, since my KDE is using QT5 and trying to install Qt4 looks like 
it is going to skrew up my entire system.


So GNURadio 3.7 itself is running fine on 20.4, but gnuradio-companion 
and gr-qtgui seem to be tricky (at least when running KDE).


Yours
Martin


On 14.05.20 17:29, Alex Humberstone wrote:
The new Ubuntu 20.04 does not include Python 2 anymore. But GNU Radio 
3.7 requires Python 2. So then can you run GNU Radio 3.7 on Ubuntu 
20.04? I think there's still a package that you can instal to add Python 
2 support in Ubuntu 20.04. I found a bunch of websites that make it 
sound like this should be possible. So I'm thinking it should still 
actually be possible to run GNU Radio 3.7 on Ubuntu 20.04. Has anyone 
actually tried this before? Does this work? Is there anything special 
that you have to do? Any help here would be super appreciated. Thanks in 
advance for your help everyone!


https://linuxconfig.org/install-python-2-on-ubuntu-20-04-focal-fossa-linux

https://linuxize.com/post/how-to-install-pip-on-ubuntu-20.04/

https://www.vultr.com/docs/how-to-install-python-2-on-ubuntu-20-04

https://www.phoronix.com/scan.php?page=news_item=Ubuntu-20.04-Clear-Python2

--
Sincerely,
Alex-M-Humberstone
PhD Student
Klipsch School of Electrical Engineering
New Mexico State University
Las Cruces, New Mexico

Re: MPSK SNR Estimation block shifts input by one

[Martin Luelf]

Dear Marcus,

thank you very much for your reply. Please see my comments inline.

On 24.03.20 16:38, Marcus Müller wrote:

Really quick answer:

 // at least 1 estimator has to look back
 set_history(2);
I totally forgot about the history feature. That makes a lot of sense 
and explains the leading zero. Plus it helps to restore my sanity :)




i.e. "works as designed"; whether that is "works as intended" is up for
discussion.


I would argue that the SNR Estimation block should skip the first 
history()-1 input samples, such that the blocks output becomes exactly 
the input without any shift.


The corresponding doc comment in 
https://github.com/gnuradio/gnuradio/blob/07741c1e5c7693a2a240bacfc5828f455fe20482/gr-digital/include/gnuradio/digital/mpsk_snr_est_cc.h#L28 
says


"It [...] passes all incoming data along to its output"

While that does not explicitly says 1:1 copy I think it is fair to say 
that a shift might come as a surprise to a user.


Is there any benefit to keeping the additional zero in the output, or 
was this simply not considered when writing the block? If the latter is 
true, I'd be happy to write a patch for it.



However, you'll see the last symbol as the first symbol of
your coming call to work!
I am not entirely sure what you mean by that. Are you explaining what a 
history of 2 does to a block? In that case this is clear to me.


But I am wondering what happened to my last input symbol.

Input: ((1+0j), (-1+0j), (1+0j), (1+0j))
I got: (0j, (1+0j), (-1+0j), (1+0j))
I would expect: (0j, (1+0j), (-1+0j), (1+0j), (1+0j))

Could it be that the last history()-1 number of samples are cut away 
from a blocks input?


Or asked in a different way: Will a block that has a history of 5 that 
gets 10 input samples (in total, might be over different calls to work) 
see 10, 14 or 15 unique (as in not counting them twice) symbols?


Yours
Martin


From the example


Best regards,
Marcus

On 24.03.20 10:33, Martin Luelf wrote:

Hi everybody,

I stumbled over a strange behavior while writing unittests for a frame
synchronization block.

The MPSK SNR Estimation block from GNURadio will output a complex zero
sample before outputting the (shifted by one) input samples.

To show this problem I use a Vector source with a sequence of BPSK
symbols and connect this source to a vector sink and the MPSK SNR
estimation block. The SNR estimation block is connected to a second sink
(the python script for this is attached at the bottom of this email).
After the flowgraph completes I print out the input data and the data
collected by the two sinks and it looks like this:

Original input data:. ((1+0j), (-1+0j), (1+0j), (1+0j))
Data from source (SNR Est input): ((1+0j), (-1+0j), (1+0j), (1+0j))
Data from SNR Est:... (0j, (1+0j), (-1+0j), (1+0j))

Note that the data from the SNR estimator has an additional 0j at the
front before the input sequence and the last symbol from the input data
is dropped.

However looking at the source code of the SNR Estimation block the first
line of the work function
(https://github.com/gnuradio/gnuradio/blob/351a22cc0e2fc05f4ca6ccb08de6ca1e83b62a70/gr-digital/lib/mpsk_snr_est_cc_impl.cc#L77)
reads:

memcpy(output_items[0], input_items[0], noutput_items *
sizeof(gr_complex));

which looks perfectly correct to me. So what is happening here? Am I
missing something? I tried searching the mailing list for shifted
samples but the results all resolve around actually wanting to shift
samples around.

Any help/hint would be greatly appreciated.

Yours
Martin



Example code to reproduce the problem (tested on maint-3.7 branch
currently at commit 351a22cc0e2fc05f4ca6ccb08de6ca1e83b62a70):

#!/usr/bin/env python2
# -*- coding: utf-8 -*-

from gnuradio import blocks
from gnuradio import digital
from gnuradio import gr

tb = gr.top_block("Test MPSK SNR Estimation")

##
# Variables
##
data_in = (1.0+0j, -1.0+0j, 1.0+0j, 1.0+0j)

##
# Blocks
##
blocks_vector_source = blocks.vector_source_c(data_in, False, 1, [])
digital_mpsk_snr_est_cc = digital.mpsk_snr_est_cc(0, 1, 0.001)
blocks_vector_sink1 = blocks.vector_sink_c(1, 1024)
blocks_vector_sink2 = blocks.vector_sink_c(1, 1024)

##
# Connections
##

# Source -> Sink 1
tb.connect((blocks_vector_source, 0), (blocks_vector_sink1, 0))

# Source -> MPSK SNR Est -> Sink 2
tb.connect((blocks_vector_source, 0), (digital_mpsk_snr_est_cc, 0))
tb.connect((digital_mpsk_snr_est_cc, 0), (blocks_vector_sink2, 0))

tb.run()

print('Original input data:. {}'.format(data_in))
print('Data from source (SNR Est input):
{}'.format(blocks_vector_sink1.data()))
print('Data from SNR Est:...
{}'.format(blocks_vector_sink2.data()))

MPSK SNR Estimation block shifts input by one

[Martin Luelf]

Hi everybody,

I stumbled over a strange behavior while writing unittests for a frame 
synchronization block.


The MPSK SNR Estimation block from GNURadio will output a complex zero 
sample before outputting the (shifted by one) input samples.


To show this problem I use a Vector source with a sequence of BPSK 
symbols and connect this source to a vector sink and the MPSK SNR 
estimation block. The SNR estimation block is connected to a second sink 
(the python script for this is attached at the bottom of this email). 
After the flowgraph completes I print out the input data and the data 
collected by the two sinks and it looks like this:


Original input data:. ((1+0j), (-1+0j), (1+0j), (1+0j))
Data from source (SNR Est input): ((1+0j), (-1+0j), (1+0j), (1+0j))
Data from SNR Est:... (0j, (1+0j), (-1+0j), (1+0j))

Note that the data from the SNR estimator has an additional 0j at the 
front before the input sequence and the last symbol from the input data 
is dropped.


However looking at the source code of the SNR Estimation block the first 
line of the work function 
(https://github.com/gnuradio/gnuradio/blob/351a22cc0e2fc05f4ca6ccb08de6ca1e83b62a70/gr-digital/lib/mpsk_snr_est_cc_impl.cc#L77) 
reads:


memcpy(output_items[0], input_items[0], noutput_items * sizeof(gr_complex));

which looks perfectly correct to me. So what is happening here? Am I 
missing something? I tried searching the mailing list for shifted 
samples but the results all resolve around actually wanting to shift 
samples around.


Any help/hint would be greatly appreciated.

Yours
Martin



Example code to reproduce the problem (tested on maint-3.7 branch 
currently at commit 351a22cc0e2fc05f4ca6ccb08de6ca1e83b62a70):


#!/usr/bin/env python2
# -*- coding: utf-8 -*-

from gnuradio import blocks
from gnuradio import digital
from gnuradio import gr

tb = gr.top_block("Test MPSK SNR Estimation")

##
# Variables
##
data_in = (1.0+0j, -1.0+0j, 1.0+0j, 1.0+0j)

##
# Blocks
##
blocks_vector_source = blocks.vector_source_c(data_in, False, 1, [])
digital_mpsk_snr_est_cc = digital.mpsk_snr_est_cc(0, 1, 0.001)
blocks_vector_sink1 = blocks.vector_sink_c(1, 1024)
blocks_vector_sink2 = blocks.vector_sink_c(1, 1024)

##
# Connections
##

# Source -> Sink 1
tb.connect((blocks_vector_source, 0), (blocks_vector_sink1, 0))

# Source -> MPSK SNR Est -> Sink 2
tb.connect((blocks_vector_source, 0), (digital_mpsk_snr_est_cc, 0))
tb.connect((digital_mpsk_snr_est_cc, 0), (blocks_vector_sink2, 0))

tb.run()

print('Original input data:. {}'.format(data_in))
print('Data from source (SNR Est input): 
{}'.format(blocks_vector_sink1.data()))
print('Data from SNR Est:... 
{}'.format(blocks_vector_sink2.data()))

Re: [Discuss-gnuradio] ControlPort setup_rpc function not called for pure message passing blocks

[Martin Luelf]

On 04.03.2016 18:05, Tom Rondeau wrote:
On Wed, Mar 2, 2016 at 4:28 AM, Martin Luelf <m...@mluelf.de 
<mailto:m...@mluelf.de>> wrote:


Dear mailing list,

we are trying to create a status overview of our receiver by using
the control ports feature. For most of our custom made blocks this
works very well and we can see the exported variables.

But for a few blocks the exported variables do not show up in the
control port monitor. After putting tracing lines in these blocks
we found out that the setup_rpc function is not called. The only
difference we could see between the blocks were the setup_rpc
function is called and the ones where it is not is that the latter
have no stream in- or output. Instead they only use the message
passing API to process data, like the mesage debug block from
GNURadio.

A minimal working example of a block whichs setup_rpc() method is
not called can be found at http://pastebin.com/cBFJCnW7 with
private and public header files at http://pastebin.com/35WhFqQ0
and http://pastebin.com/zb4jBRAw

If we run this block and feed messages to it, we get the following
output:
constructor()
ControlPort Monitor running.
INFO: Apache Thrift: -h localhost -p 40444
monitor::endpoints() = -h localhost -p 40444
process frame()
process frame()
[...]
process frame()
process frame()
running: ['gr-ctrlport-monitor', 'localhost', '40444']
process frame()
process frame()
[...]
process frame()
process frame()

We would expect to see an additional line at the beginning saying
"setup_rpc()" (see line 71 of the c++ code) and consequently see
the variable "testval" in the control port monitor, like it does
for our working blocks.

The above output is generated with GNURadio version
3.7.8.1-229-g51c0426a manually compiled from source on an Ubuntu
trusty system (64 bit).

The only difference we could find between the blocks working as
expected and the ones that do not, is that they use streaming for
data transport, i.e. that their work or general_work function has
some actual data processing and their gr::io_signature is not set
to (0,0,0).

I kindly ask for your help to find out why the setup_rpc function
is not called for our example block posted above and what we can
do to change this.

Yours sincerely
Martin Luelf


Martin,

This definitely sounds like a bug for a case that wasn't planned for 
initially. Can you open up a bug report with this information on our 
Issue tracker on gnuradio.org <http://gnuradio.org>?


Thanks,
Tom



I created a new bug #907 that can be viewed at 
http://gnuradio.org/redmine/issues/907


Thanks for your support.
Martin


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

Re: [Discuss-gnuradio] ControlPort setup_rpc function not called for pure message passing blocks

[Martin Luelf]

On 07.03.2016 14:23, Tom Rondeau wrote:
On Sun, Mar 6, 2016 at 6:08 AM, Martin Lülf <m...@mluelf.de 
<mailto:m...@mluelf.de>> wrote:


Dear Tom,

thanks for your reply.

I created an account on the gnuradio.org <http://gnuradio.org>
platform. A day later the account is still disabled, so I assume
there is a manual confirmation required.

So I kindly ask somebody on the list with the right permissions to
activate my account "MartinLuelf" with the same Email address as I
use for this mailing list.

Thank you and have a nice weekend eveybody.
Martin



I have activated your account.



Hi Tom,

thanks for the activation, I can now log in. However I can't find a 
button or link to create a new bug/issue. According to the wiki there 
should be an entry "New Issue" appearing in the navigation, but I can't 
find it anywhere. Do I need to have additional rights to open tickets?


Martin


Now, if someone can get rid of spammers, we wouldn't need to do this...

Tom

On 03/04/16 18:05, Tom Rondeau wrote:

    On Wed, Mar 2, 2016 at 4:28 AM, Martin Luelf <m...@mluelf.de
<mailto:m...@mluelf.de>
<mailto:m...@mluelf.de <mailto:m...@mluelf.de>>> wrote:

Dear mailing list,

we are trying to create a status overview of our receiver
by using
the control ports feature. For most of our custom made
blocks this
works very well and we can see the exported variables.

But for a few blocks the exported variables do not show up
in the
control port monitor. After putting tracing lines in these
blocks we
found out that the setup_rpc function is not called. The only
difference we could see between the blocks were the setup_rpc
function is called and the ones where it is not is that
the latter
have no stream in- or output. Instead they only use the
message
passing API to process data, like the mesage debug block
from GNURadio.

A minimal working example of a block whichs setup_rpc()
method is
not called can be found at http://pastebin.com/cBFJCnW7
with private
and public header files at http://pastebin.com/35WhFqQ0 and
http://pastebin.com/zb4jBRAw

If we run this block and feed messages to it, we get the
following
output:
constructor()
ControlPort Monitor running.
INFO: Apache Thrift: -h localhost -p 40444
monitor::endpoints() = -h localhost -p 40444
process frame()
process frame()
[...]
process frame()
process frame()
running: ['gr-ctrlport-monitor', 'localhost', '40444']
process frame()
process frame()
[...]
process frame()
process frame()

We would expect to see an additional line at the beginning
saying
"setup_rpc()" (see line 71 of the c++ code) and
consequently see the
variable "testval" in the control port monitor, like it
does for our
working blocks.

The above output is generated with GNURadio version
3.7.8.1-229-g51c0426a manually compiled from source on an
Ubuntu
trusty system (64 bit).

The only difference we could find between the blocks
working as
expected and the ones that do not, is that they use
streaming for
data transport, i.e. that their work or general_work
function has
some actual data processing and their gr::io_signature is
not set to
(0,0,0).

I kindly ask for your help to find out why the setup_rpc
function is
not called for our example block posted above and what we
    can do to
change this.

Yours sincerely
Martin Luelf


Martin,

This definitely sounds like a bug for a case that wasn't
planned for
initially. Can you open up a bug report with this information
on our
Issue tracker on gnuradio.org <http://gnuradio.org>
<http://gnuradio.org>?

Thanks,
Tom





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

[Discuss-gnuradio] ControlPort setup_rpc function not called for pure message passing blocks

[Martin Luelf]

Dear mailing list,

we are trying to create a status overview of our receiver by using the 
control ports feature. For most of our custom made blocks this works 
very well and we can see the exported variables.


But for a few blocks the exported variables do not show up in the 
control port monitor. After putting tracing lines in these blocks we 
found out that the setup_rpc function is not called. The only difference 
we could see between the blocks were the setup_rpc function is called 
and the ones where it is not is that the latter have no stream in- or 
output. Instead they only use the message passing API to process data, 
like the mesage debug block from GNURadio.


A minimal working example of a block whichs setup_rpc() method is not 
called can be found at http://pastebin.com/cBFJCnW7 with private and 
public header files at http://pastebin.com/35WhFqQ0 and 
http://pastebin.com/zb4jBRAw


If we run this block and feed messages to it, we get the following output:
constructor()
ControlPort Monitor running.
INFO: Apache Thrift: -h localhost -p 40444
monitor::endpoints() = -h localhost -p 40444
process frame()
process frame()
[...]
process frame()
process frame()
running: ['gr-ctrlport-monitor', 'localhost', '40444']
process frame()
process frame()
[...]
process frame()
process frame()

We would expect to see an additional line at the beginning saying 
"setup_rpc()" (see line 71 of the c++ code) and consequently see the 
variable "testval" in the control port monitor, like it does for our 
working blocks.


The above output is generated with GNURadio version 
3.7.8.1-229-g51c0426a manually compiled from source on an Ubuntu trusty 
system (64 bit).


The only difference we could find between the blocks working as expected 
and the ones that do not, is that they use streaming for data transport, 
i.e. that their work or general_work function has some actual data 
processing and their gr::io_signature is not set to (0,0,0).


I kindly ask for your help to find out why the setup_rpc function is not 
called for our example block posted above and what we can do to change this.


Yours sincerely
Martin Luelf

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

Re: [Discuss-gnuradio] Initial state options for Viterbi algorithm

[Martin Luelf]

Hi,

if you encode a continuous stream of data you will not reset your encoder
state in between. However if you want to decode the stream you want to
perform blockwise operation to keep the latency and memory requirements
down. In this cases it makes sense for me to reuse the last state as the
initial state of the next block at the decoder.

If your underlying data is however of a block nature (e.g. frames) I agree
with you that it makes sense to reset the initial states.

Yours
Martin



 I do not see the need for such an option:

 regarding the initial state at the encoder, I do not see why anyone
 wouldn't reset the initial state of a block but use the state of a
 previous block.

 Say it another way, if you want to decode two blocks by setting the
 initial state of one as the final state of the other, why don't you
 run the Viterbi algorithm for the entire two-block set of data in one
 shot

 best
 Achilleas

 ___
 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] create uniform PMT vector from python

[Martin Luelf]

 Hi all,

 Is there a way to create a uniform PMT vector from python?

 I can use, for example, 'pmt.make_c32vector(length, value)' to create
 a vector where each element is 'value' but I don't see a way to modify
 these values from python.

 If there isn't, are there any objections to overloading these
 functions to take std::vectors as input so that we can pass in lists
 from python?

 Cheers,
 Ben

Hi,

I remember, I wasn't sure about the supposed way of doing that either for
a u8vector. Finally I used the set method to set the individual elements
like this:
--
# elements as list
values = (0xA1, ...)

# create pmt vector with one default value for all elements
pmtvector = pmt.pmt_make_u8vector(len(values), 0x00)

# set the individual elements
for i in xrange(len(values)) :
pmt.pmt_u8vector_set(pmtvector, i, values[i])
--

Not nice, but it works for me. Although I agree that passing a list at
construction would be very handy.

Yours
Martin


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

[Discuss-gnuradio] Set USRP clock to system time in GRC

[Martin Luelf]

Hi list,

I am wondering if it is possible to set a USRP clock to the system time
within GRC. I know this is straightforward in Python and C++ using the
set_time_now method, but as I use GRC a lot I don't want to edit the
generated python files everytime after I do some changes to my flowgraph.

I already checked the source (master a few weeks old) but there seems to
be no call of set_time_now or set_time_next_pps. (I believe there have
been no patches the last weeks regarding this?)

If there is no way of doing this in GRC right now, is there any reason not
to add this to the UHD sink/source to set the clocks to system time by
default?

Have a nice weekend.
Yours
Martin Luelf


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

Re: [Discuss-gnuradio] Simultaneously send data and store it in file with high sample rate

[Martin Luelf]

 Hi Martin,
 Thanks a lot. I am using gr-digital narrowband examples,with little bit of
 changes in the code.I am still not able to get full sample rate of
 25MHz.At
 max i am getting 2MHz sample rate.
 I attached my code ,can you please let me know what might be the reason.Is
 it because of processing time or some other reason.

 parameters i am passing from terminal
 sudo python test.py -f 5.825e9 --rx-freq 5.825e9 --tx-gain 31.5 --rx-gain
 31.5  -m dbpsk -a=serial=ECR13W5UP -r 1e6

 if i try to change -r(bit rate)   to  2e6  i am getting overflow.

 Thanks.


 On Fri, Mar 22, 2013 at 7:07 PM, Martin Luelf m...@mluelf.de wrote:

  Hi Martin,
 
  Can you please show me an example.. How to write connect statement?
 
  Thanks
 
 
  On Thu, Mar 21, 2013 at 6:26 PM, Martin Luelf m...@mluelf.de wrote:
 
   Hi,
   How to simultaneously transmit data to usrp and also store it in a
  file.?
   I
   ran two separate flow graphs.But i want to have a sample rate of
  25Mhz.Is
   it possible to do it.
  
   I want the same thing in receiver side also(simultaneously detect
 the
   packet  and store the data)
  
   I am using USRPN210 and Ubuntu 12.04
  
   Thanks.
 
  Hi,
 
  you can connect a block's output to as many inputs as you want. So
 take
  tha last block in your chain that generates your signal and connect
 it
  both to a uhd sink (which will make the USRP transmitt the signal)
 and a
  file sink (which will write the same samples to a file).
 
  Same goes for the receiver side. If you use GRC just add another
  connection from a block's out port to another ones in port and the
  output
  will be send to both blocks.
 
  Yours
  Martin
 

 Hi,

 first of all please make sure that you reply to the list rather than to
 the individual persons, or CC the list so that answers are also
 available
 for anyone who might have a similar question in the future.

 The question how to do a block connect is confusing me a bit. Maybe
 there
 is a misunderstanding? You should already have done block connections
 when
 setting up your flowgraphs.

 Anyway what I mean is a standard connection of two GNURadio blocks, so
 in
 GRC it might look like this (I know I am not an ASCII artist, sorry)

  |(Your signal processing block)
 (UHD Source)-|
  |(File Sink)

 This should lead to python code like this

 ##
 # Blocks
 ##
 self.uhd_usrp_source_0 = uhd.usrp_source(...)
 self.yourblock_0 = yourmodule.yourblock(...)
 self.file_sink_0 = gr.file_sink(gr.sizeof_gr_complex*1, ...)
 ##
 # Connections
 ##
 self.connect((self.uhd_usrp_source_0, 0), (self.file_sink_0, 0))
 self.connect((self.uhd_usrp_source_0, 0), (self.yourblock_0, 0))

 Yours
 Martin




Hi,

you are passing a serial and not an IP address as argument, that makes me
assume you have a USB based USRP like the USRP1? I don't know the exact
number but I think the rate limit you can achieve over the USB is
somewhere around 2MSamples/sec, but definitely below 25MSamples/sec. For
that you would need a Gigabit Ethernet USRP. Even if the connection for
the USRP is fast enough for higher rates you can still run into overflows
if your code is to slow to follow up with the signal processing. In this
case either optimize your code, get a better system (mainly RAM and CPU)
or simplify your flow graph to do less processing overall.

Martin


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

Re: [Discuss-gnuradio] Simultaneously send data and store it in file with high sample rate

[Martin Luelf]

 Hi Martin,

 Can you please show me an example.. How to write connect statement?

 Thanks


 On Thu, Mar 21, 2013 at 6:26 PM, Martin Luelf m...@mluelf.de wrote:

  Hi,
  How to simultaneously transmit data to usrp and also store it in a
 file.?
  I
  ran two separate flow graphs.But i want to have a sample rate of
 25Mhz.Is
  it possible to do it.
 
  I want the same thing in receiver side also(simultaneously detect the
  packet  and store the data)
 
  I am using USRPN210 and Ubuntu 12.04
 
  Thanks.

 Hi,

 you can connect a block's output to as many inputs as you want. So take
 tha last block in your chain that generates your signal and connect it
 both to a uhd sink (which will make the USRP transmitt the signal) and a
 file sink (which will write the same samples to a file).

 Same goes for the receiver side. If you use GRC just add another
 connection from a block's out port to another ones in port and the
 output
 will be send to both blocks.

 Yours
 Martin


Hi,

first of all please make sure that you reply to the list rather than to
the individual persons, or CC the list so that answers are also available
for anyone who might have a similar question in the future.

The question how to do a block connect is confusing me a bit. Maybe there
is a misunderstanding? You should already have done block connections when
setting up your flowgraphs.

Anyway what I mean is a standard connection of two GNURadio blocks, so in
GRC it might look like this (I know I am not an ASCII artist, sorry)

 |(Your signal processing block)
(UHD Source)-|
 |(File Sink)

This should lead to python code like this

##
# Blocks
##
self.uhd_usrp_source_0 = uhd.usrp_source(...)
self.yourblock_0 = yourmodule.yourblock(...)
self.file_sink_0 = gr.file_sink(gr.sizeof_gr_complex*1, ...)
##
# Connections
##
self.connect((self.uhd_usrp_source_0, 0), (self.file_sink_0, 0))
self.connect((self.uhd_usrp_source_0, 0), (self.yourblock_0, 0))

Yours
Martin


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

Re: [Discuss-gnuradio] Simultaneously send data and store it in file with high sample rate

[Martin Luelf]

 Hi,
 How to simultaneously transmit data to usrp and also store it in a file.?
 I
 ran two separate flow graphs.But i want to have a sample rate of 25Mhz.Is
 it possible to do it.

 I want the same thing in receiver side also(simultaneously detect the
 packet  and store the data)

 I am using USRPN210 and Ubuntu 12.04

 Thanks.

Hi,

you can connect a block's output to as many inputs as you want. So take
tha last block in your chain that generates your signal and connect it
both to a uhd sink (which will make the USRP transmitt the signal) and a
file sink (which will write the same samples to a file).

Same goes for the receiver side. If you use GRC just add another
connection from a block's out port to another ones in port and the output
will be send to both blocks.

Yours
Martin


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

Re: [Discuss-gnuradio] build-gnuradio on Scientific Linux 6.3

[Martin Luelf]

 Possibly Ubuntu sets up /usr/local to be regular-user
 writeable, but that would be a horrible security flaw.

At least for my Ubuntu 12.04 /usr/local is owned by root:root with 0755
permissions and everything else would have given me nightmares ;)

Maybe you started the script with sudo, instead of letting the script
itself call sudo, then you would have had the necessary permissions.

Yours
Martin


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

Re: [Discuss-gnuradio] uhd_fft and benchmark_tx

[Martin Luelf]

 when i run uhd_fft it runs ok but parallel i cannot run benchmark
 so i must close the uhd_fft to run the benchmark_tx

 as message appears that RuntimeError: LookupError: KeyError: No devices
 found for -
 Empty Device Address
 although while searching i find video running both togothers. so how can i
 do this to see transmitted signal at certain frequency from the benchmark
 transmitted

Hi,

a USRP device can only be accessed by one process at a time. So when you
run uhd_fft this process occupies your USRP. When starting benchmark_tx
the UHD lib looks for other available USRPs and trhows LookupError because
it can not find any unused USRP device (I assume you only have one USRP
device connected?) unless you stop uhd_fft before (in which case your USRP
is available again)

Yours
Martin


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

Re: [Discuss-gnuradio] Developing with C++ but not python

[Martin Luelf]

 Hi,
 I think python file means data go downstream without interacting
 with other data stream.And I have seen several example writen in c++ and
 they all contain a gr_top_block which makes them similar to python
 files.Any body have the experience developing in c++?And what you think
 is the major difficulity(except more effort) compared to python?
 Thanks.


Hi,

I am not completely sure I understood your question, but as far as I can
tell you are concerned about running python next to C++ (I guess for
performance reasons.)

The core GNURadio application, also the top_blocks are C++ code, so all
the data processing and data passing is done in compiled C++ code (Unless
you decide to write blocks in python of course).
Python is only used for setup and connection purposes and use
automatically generated wrappers for the C++ code (so you call shared C++
libraries from python). See also these two FAQs
http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#Why-bother-with-Python-I-just-want-to-code-in-C

Martin


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

Re: [Discuss-gnuradio] Block continues after EOF

[Martin Luelf]

 Dear List,

 I have another problem with stopping my C++ block. My block receives blobs
 of bytes as messages over the new message passing interface and outputs
 them as a byte stream. At some place I receive an EOF message, set a flag
 and continue to empty my buffer in the work method. Once the buffer is
 empty I signal EOF to the flowgraph by returning -1 from general_work.
 However after that my work function keeps getting called.

 My general_work function looks like this:

 int general_work(int noutput_items, gr_vector_int ninput_items,
 gr_vector_const_void_star input_items, gr_vector_void_star output_items)
 {
   printf(work function called\n);

   if(d_stop  d_queue.size() == 0) {
   // signal EOF
   printf(Signal EOF\n);
   return -1;
   }

 int num_out;
   // Generate the actual output
 // ...

   return num_out;
 }

 And the output I get looks like this:
 work function called
 work function called
 work function called
 Signal EOF
 work function called
 work function called
 work function called
 work function called
 ...
 Until I stop the whole flowgraph with Ctrl+C

 What am I missing here? If I understood correctly the work function should
 not be called anymore after signalling EOF, since there is by definition
 of EOF, nothing more to get.

 Yours
 Martin

Oh boy, starting again with a clear head this morning I found my mistake
almost immediately. In fact I had another instance of the same block
running, so the output I posted was actually from two blocks from which
one exited as expected, the other one kept running.

Sorry for the false alarm,
Martin


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

[Discuss-gnuradio] Block continues after EOF

[Martin Luelf]

Dear List,

I have another problem with stopping my C++ block. My block receives blobs
of bytes as messages over the new message passing interface and outputs
them as a byte stream. At some place I receive an EOF message, set a flag
and continue to empty my buffer in the work method. Once the buffer is
empty I signal EOF to the flowgraph by returning -1 from general_work.
However after that my work function keeps getting called.

My general_work function looks like this:

int general_work(int noutput_items, gr_vector_int ninput_items,
gr_vector_const_void_star input_items, gr_vector_void_star output_items)
{
printf(work function called\n);

if(d_stop  d_queue.size() == 0) {
// signal EOF
printf(Signal EOF\n);
return -1;
}

int num_out;
// Generate the actual output
// ...

return num_out;
}

And the output I get looks like this:
work function called
work function called
work function called
Signal EOF
work function called
work function called
work function called
work function called
...
Until I stop the whole flowgraph with Ctrl+C

What am I missing here? If I understood correctly the work function should
not be called anymore after signalling EOF, since there is by definition
of EOF, nothing more to get.

Yours
Martin


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