Re: [Discuss-gnuradio] Integration of python's time.time() and work() calls

[Marcus Müller]

Hi Anil,

On 05/29/2015 04:29 AM, Anil Kumar Yerrapragada wrote:
> >>Or is there a way to make sure that the in-buffer gets updated
> multiple times within the same work call?
>
> Will placing the work function inside a while 1 do the trick?
Never do that. Your job as GR user is to write the work() function. GNU
Radio will call it, whenever data is available. You can't make data
appear faster than it appears, and you can rely on GR to call your
work() as soon as possible. Just don't worry about doing this yourself.

Write your work() function in a manner that consumes as many items as it
can whenever it's called, and return exactly that number. GNU Radio will
take care of the rest :)
> But I guess the issue with that is, as long as data is available, the
> scheduler calls work function again and again anyway. 
Indeed!
>
>
> I'm still a little muddled up about this. I have read a lot of the
> posts on the forum and the tutorials on the website as well.
GNU Radio's primary job is to keep things simple for you: it allows
developers to just write their algorithms inside a work function. All
they have to do is take the input they get, generate the output they
want, and tell GNU Radio how much has been done.

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

[Discuss-gnuradio] can't install gnuradio 3.7.7.1 and newest UHD

[Nemanja Savic]

Hi all,

I am stil using gnuradio 3.6.5.1 and yesterday I wanted to install newest
version of both gnuradio and UHD driver. I wanted to install them on some
different path and to preserve working environment until I am sure that
newcomers work.

First I downloaded and built UHD. I followed instructions and the first
problem was that I couldn't run test. It simply says can't find test.
However I installed it (on a different path where my old UHD driver is).

Next I built gnuradio. In ccmake i provided new paths to the fresh UHD:

UHD_DIR   /scr1/nemanja/install/lib64/cmake/uhd

UHD_INCLUDE_DIRS   /scr1/nemanja/install/include
UHD_LIBRARIES
/scr1/nemanja/install/lib64/libgnuradio-uhd-3.7.7.so.0.0.0

However at the end of the building process I get following error:

make[2]: *** No rule to make target
`/scr1/nemanja/install/lib64/libgnuradio-uhd-3.7.7.so.0.0.0', needed by
`gr-uhd/lib/libgnuradio-uhd-3.7.7.so.0.0.0'.  Stop.
make[1]: *** [gr-uhd/lib/CMakeFiles/gnuradio-uhd.dir/all] Error 2
make: *** [all] Error 2

What might be the problem here?

Thanx,

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

[Discuss-gnuradio] What if noutput_itmes is too short?

[Jeon]

I am trying to remove `preamble` and `start frame delimiter` from a frame
and only the payload will be passed to the next block.

While in debugging, `ninput_items` is 7742, and `noutput_items` is 4096,
for instance. An offset where the frame starts is 790.

Simple calculation gives me that 7742 - 790 = 6952 samples should be passed
to the next block. But output space given is only 4096. Thus, I can only
pass 4096 samples and 6952 - 4096 = 2856 samples will be discarded. But, I
need them to be passed, too.

Even worse, a stream of samples are coming continuously from a previous
block.

Will it be helpful if I have some very long buffer in a block? I don't
think it works since `noutput_items` is always smaller than `ninput_items`
every time the block runs `general_work()`. In this case, I think the
buffer will be overflowed.

The link below is the log that shows

`i`/`ninput_itmes` and `o`/`noutput_items`,

where `i` and `o` are input and output indices. When `ninput_itmes` and
`noutput_items` change, it means a new `general_work` is called.

Log (it's quite long...): https://bitbucket.org/snippets/gsongsong/By8x

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

Re: [Discuss-gnuradio] What if noutput_itmes is too short?

[Jeon]

After posting the previous thread, I've searched APIs from GNU Radio
doxygen.

Several candidates have been found.

1. [`produce()`](
http://gnuradio.org/doc/doxygen/classgr_1_1block.html#aa5581727d057bdd8113f8b2a3fc5bd66
)
2. [`set_min_noutput_items()`](
http://gnuradio.org/doc/doxygen/classgr_1_1block.html#a65cfc579150dc4d10c6180d3365aa9a8
)
3. [`set_min_output_buffer()`](
http://gnuradio.org/doc/doxygen/classgr_1_1block.html#a9d10e3f6747f91b215abe81b60a003d5
)
4. [`expand_minmax_buffer()`](
http://gnuradio.org/doc/doxygen/classgr_1_1block.html#a9bbf96f6a81d5c289934a68ef44dd1b4
)

I think I can combine `produce()` and `set_min_noutput_items()` to
**enlarge** the `noutput_items`

If I get wrong, please let me know.

Regards,
Jeon.

2015년 5월 29일 (금) 오후 8:47, Jeon 님이 작성:

> I am trying to remove `preamble` and `start frame delimiter` from a frame
> and only the payload will be passed to the next block.
>
> While in debugging, `ninput_items` is 7742, and `noutput_items` is 4096,
> for instance. An offset where the frame starts is 790.
>
> Simple calculation gives me that 7742 - 790 = 6952 samples should be
> passed to the next block. But output space given is only 4096. Thus, I can
> only pass 4096 samples and 6952 - 4096 = 2856 samples will be discarded.
> But, I need them to be passed, too.
>
> Even worse, a stream of samples are coming continuously from a previous
> block.
>
> Will it be helpful if I have some very long buffer in a block? I don't
> think it works since `noutput_items` is always smaller than `ninput_items`
> every time the block runs `general_work()`. In this case, I think the
> buffer will be overflowed.
>
> The link below is the log that shows
>
> `i`/`ninput_itmes` and `o`/`noutput_items`,
>
> where `i` and `o` are input and output indices. When `ninput_itmes` and
> `noutput_items` change, it means a new `general_work` is called.
>
> Log (it's quite long...): https://bitbucket.org/snippets/gsongsong/By8x
>
> Regards,
> Jeon.
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] What if noutput_itmes is too short?

[Marcus Müller]

Hi Jeon,


On 05/29/2015 01:46 PM, Jeon wrote:
> I am trying to remove `preamble` and `start frame delimiter` from a
> frame and only the payload will be passed to the next block.
>
> While in debugging, `ninput_items` is 7742, and `noutput_items` is
> 4096, for instance. An offset where the frame starts is 790.
>
> Simple calculation gives me that 7742 - 790 = 6952 samples should be
> passed to the next block. But output space given is only 4096. Thus, I
> can only pass 4096 samples and 6952 - 4096 = 2856 samples will be
> discarded. But, I need them to be passed, too.

There's no reason not to pass through your payload in parts, if you
implement a state machine with a counter for remaining items to pass
through in your block.
However, there's an advantage to waiting for the whole payload to be on
your input at once, which I'll explain further down.
Does your payload always have the same length? In that case, your
forecast should always demand payload_length input items to produce any
amount of output items -- that way, you can make sure that at *one
point*, you get the whole payload into your input buffer.

No matter what you really do, you will need to use a state machine of
some kind.
In your case, that's comparatively easy: Just check, at the beginning of
each general_work call, whether you're in pass-through mode, or in
"search preamble mode", etc, and let your work act based upon that. For
example, assume you're in search preamble mode, you find a preamble, so
you consume all items up to the end of that preamble, and set your state
to "pass through", and then return from general_work. Before GNU Radio
calls you next time, it will ask forecast() how many input items you
need. Forecast always says it needs payload_length items, so at the
point where work is actually called in "pass through" mode, you *should*
have at least payload_length input items; let your block consume and
produce these items, switch to "search preamble mode", and return.
>
> Even worse, a stream of samples are coming continuously from a
> previous block.
Lucky you! You have GNU Radio, which makes sure there's only one
instance of your general_work being run at once, and presenting you with
all the items you did not consume in the previous general_work calls.
>
> Will it be helpful if I have some very long buffer in a block? I don't
> think it works since `noutput_items` is always smaller than
> `ninput_items` every time the block runs `general_work()`.
That's not generally the case. It might be the case here, but that
simply means that the downstream block isn't consuming the whole buffer,
or your upstream items are larger, or your upstream block is just much
faster at producing items than you and your downstream blocks are at
consuming them.

If you just try to rely on GNU Radio's buffers, you would be safe from
something like buffer overflows happening -- GNU Radio will only call
the upstream's general_work function if there is enough space in its
output buffer (which is your input buffer).

Personally, I think what you're doing is a complicated task, so I have a
lot of respect for the effort you're putting into this.
I'd try to avoid the complexity by /not/ doing this in one block -- use
a preamble correlator to mark the beginning of your frame with a stream
tag. Then, use a state-machine block to only copy the payload_length
items after such a tag (a whole payload at a time), adding a tag on the
first item containing the length of the payload as long:
I mentioned above there's an advantage to passing the whole payload at
once; what you have when you have a length tag on the first item of
contigous packet items is a tagged stream. Tagged stream blocks are a
GNU Radio concept dedicated to processing packeted data, in which work()
methods are always called with the whole packet at once [1].

Best regards,
Marcus

[1] http://gnuradio.org/doc/doxygen/page_tagged_stream_blocks.html
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GRC Reacting Slowly

[Andreas Ladanyi]

Hi Murray,

thats an interesting fact.

My project has a lot (i didnt count them) of blocks. I have the same 
delay problem on my PC and on my embedded device.  On the embedded 
device its slower than on my pc :-)


If i use only a few blocks than the delay is short.

So i think your theory and suggestion is great.

Andy


Am 27.05.2015 um 21:08 schrieb Murray Thomson:
I had this problem for a while when using a large number of blocks. 
The cause, I think, is that the companion checks if the flowgraph is 
correct after every change. You will only be able to compile if it's 
correct (blocks are connected, variable names exist...).
If this is really the reason, It would be nice to have an icon that, 
when unselected disables this check and when selected it checks the 
flowgraph and enables the compile and run options if everything is ok.


Regards,
Murray



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

Re: [Discuss-gnuradio] SDRA, Programme complete

[Iluta V]

Thank you very much, Markus, for your update on SDRA programme. I look
forward to coming!

Hopefully you would know how to get to Friedrichshafen. Would it be better
to fly to Liechtenstein or Switzerland (Zurich) if there is reliable
transport or still to Munich (though it looks 3x further away than German
border).

Maybe you could suggest any major airport hub with transport up to there?

Thank you very much.

BR,

Iluta

On Fri, May 29, 2015 at 1:24 AM, Markus Heller  wrote:

> Dear List,
>
> please note that the programme of the SDRA-2015 is now complete.
>
> http://www.sdra-2015.de/pages/programme.html
>
> We have also finalized the timetable now.
>
> I'll be happy to welcome many of you at Friedrichshafen! The SDRA will
> take place on June 27.
>
> vy73
> markus
> dl8rds
>
>
> ___
> 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] GRC Reacting Slowly

[Koslowski, Sebastian (CEL)]

Hey,

so, I timed the flowgrah update steps rewrite, validate, create labels,
create shapes and it turns out most time is actually spent in validate.
However, for some reason the validate step currently performs the
evaluation of the params and this is also where it spends almost all of
its time. So, moving this to rewrite and making validate optional is
certainly possible, but doesn't help (because then validate takes no
time to run). Further profiling is required.

Sebastian

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

Re: [Discuss-gnuradio] SDRA, Programme complete

[Marcus Müller]

Hi Iluta,

over German Railroad (Deutsche Bahn)'s website www.bahn.de you can plan
and book train tickets from both München and Zürich Flughafen
(==airport); just checked, takes about two hours and 30 € to get from
Zurich airport to Friedrichshafen Stadt. If you get a connection
including a transport called "Schiff", you'll be taking a ferry over the
Lake Constance (Bodensee). Depending on the weather, that might be a
nice trip :)
Munich airport (München Flughafen) -- Friedrichshafen Stadt takes a
little less than four hours, I'd estimate.
There's Stuttgart Flughafen (3 hours by train), and possibly Basel
EuroAirport (about 4 hours by train).
In fact, Friedrichshafen does have an international airport (to my own
surprise) that at least Lufthansa services.
The biggest German airport is Frankfurt Flughafen (FRA), and if you take
a fast train, you'll reach Friedrichshafen in but 3:30h -- so if in
doubt, Frankfurt is your choice. You might want to stay away from
Frankfurt/Hahn (HHN), that's the discount airport somewhere in the
middle of nowhere, and not really close to Frankfurt.

Liechtenstein (the whole country) is about 2 times as big as
Friedrichshafen; they didn't try to squeeze an airport into that :D

by the way, google.com/flights lets you choose FDH as target airport,
and add nearby airports so you can quickly chose cheap/comfortable flights.

Best regards,
Marcus

On 05/29/2015 03:53 PM, Iluta V wrote:
> Thank you very much, Markus, for your update on SDRA programme. I look
> forward to coming!
>
> Hopefully you would know how to get to Friedrichshafen. Would it be
> better to fly to Liechtenstein or Switzerland (Zurich) if there is
> reliable transport or still to Munich (though it looks 3x further away
> than German border).
>
> Maybe you could suggest any major airport hub with transport up to there?
>
> Thank you very much.
>
> BR,
>
> Iluta
>
> On Fri, May 29, 2015 at 1:24 AM, Markus Heller  > wrote:
>
> Dear List,
>
> please note that the programme of the SDRA-2015 is now complete.
>
> http://www.sdra-2015.de/pages/programme.html
>
> We have also finalized the timetable now.
>
> I'll be happy to welcome many of you at Friedrichshafen! The SDRA will
> take place on June 27.
>
> vy73
> markus
> dl8rds
>
>
> ___
> 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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] SDRA, Programme complete

[Iluta V]

Dear Marcus, Thanks a lot! Switzerland and Zurich airport with a travel
over the lake sound excellent!

Good reminder to stay away from Frankfurt. Actually I've been to all
Frankfurt airports (FRA, ZFR, HHN), and depending on purpose of travel all
of these airports are very good!

google.com/flights is an interesting find, I didn't know about such.

Wiil be at SDR Academy on June 27.

My best regards,

Iluta



On Fri, May 29, 2015 at 5:45 PM, Marcus Müller 
wrote:

>  Hi Iluta,
>
> over German Railroad (Deutsche Bahn)'s website www.bahn.de you can plan
> and book train tickets from both München and Zürich Flughafen (==airport);
> just checked, takes about two hours and 30 € to get from Zurich airport to
> Friedrichshafen Stadt. If you get a connection including a transport called
> "Schiff", you'll be taking a ferry over the Lake Constance (Bodensee).
> Depending on the weather, that might be a nice trip :)
> Munich airport (München Flughafen) -- Friedrichshafen Stadt takes a little
> less than four hours, I'd estimate.
> There's Stuttgart Flughafen (3 hours by train), and possibly Basel
> EuroAirport (about 4 hours by train).
> In fact, Friedrichshafen does have an international airport (to my own
> surprise) that at least Lufthansa services.
> The biggest German airport is Frankfurt Flughafen (FRA), and if you take a
> fast train, you'll reach Friedrichshafen in but 3:30h -- so if in doubt,
> Frankfurt is your choice. You might want to stay away from Frankfurt/Hahn
> (HHN), that's the discount airport somewhere in the middle of nowhere, and
> not really close to Frankfurt.
>
> Liechtenstein (the whole country) is about 2 times as big as
> Friedrichshafen; they didn't try to squeeze an airport into that :D
>
> by the way, google.com/flights lets you choose FDH as target airport, and
> add nearby airports so you can quickly chose cheap/comfortable flights.
>
> Best regards,
> Marcus
>
>
> On 05/29/2015 03:53 PM, Iluta V wrote:
>
>Thank you very much, Markus, for your update on SDRA programme. I look
> forward to coming!
>
>  Hopefully you would know how to get to Friedrichshafen. Would it be
> better to fly to Liechtenstein or Switzerland (Zurich) if there is reliable
> transport or still to Munich (though it looks 3x further away than German
> border).
>
>  Maybe you could suggest any major airport hub with transport up to there?
>
>  Thank you very much.
>
>  BR,
>
>  Iluta
>
> On Fri, May 29, 2015 at 1:24 AM, Markus Heller  wrote:
>
>> Dear List,
>>
>> please note that the programme of the SDRA-2015 is now complete.
>>
>> http://www.sdra-2015.de/pages/programme.html
>>
>> We have also finalized the timetable now.
>>
>> I'll be happy to welcome many of you at Friedrichshafen! The SDRA will
>> take place on June 27.
>>
>> vy73
>> markus
>> dl8rds
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] What if noutput_itmes is too short?

[Jeon]

Thank you for your reply, Marcus.

Now I'm getting a little bit more.

As I understand, if I consume(0, n), where n is less than ninput_items,
then only n samples at the front of input_items[] are consumed and
unconsumed part remains. And then, at the next call of general_work(),
incoming samples are appended at the end of input_item[]. Is this right?

If it is right, I can get a single whole payload by not consuming input
samples after some time passed...

However, I am still doubtful that input_items[] will not be appended as I
think since output buffer at the previous block isn't cleared enough as
`consume()` is not called.

Well... Does `forecast()` which you've mentioned make the previous block
can send more streams and the current block can received them? So far, I
understand `forecast()` acts as just a blocker unless enough samples are
given.

In the developing stage, I am using fixed length payload. But, I want to
make it work with arbitrary length (but not too long).

Regards,
Jeon.

On Fri, May 29, 2015 at 9:52 PM Marcus Müller 
wrote:

>  Hi Jeon,
>
>
>
> On 05/29/2015 01:46 PM, Jeon wrote:
>
> I am trying to remove `preamble` and `start frame delimiter` from a frame
> and only the payload will be passed to the next block.
>
>  While in debugging, `ninput_items` is 7742, and `noutput_items` is 4096,
> for instance. An offset where the frame starts is 790.
>
>  Simple calculation gives me that 7742 - 790 = 6952 samples should be
> passed to the next block. But output space given is only 4096. Thus, I can
> only pass 4096 samples and 6952 - 4096 = 2856 samples will be discarded.
> But, I need them to be passed, too.
>
>
> There's no reason not to pass through your payload in parts, if you
> implement a state machine with a counter for remaining items to pass
> through in your block.
> However, there's an advantage to waiting for the whole payload to be on
> your input at once, which I'll explain further down.
> Does your payload always have the same length? In that case, your forecast
> should always demand payload_length input items to produce any amount of
> output items -- that way, you can make sure that at *one point*, you get
> the whole payload into your input buffer.
>
> No matter what you really do, you will need to use a state machine of some
> kind.
> In your case, that's comparatively easy: Just check, at the beginning of
> each general_work call, whether you're in pass-through mode, or in "search
> preamble mode", etc, and let your work act based upon that. For example,
> assume you're in search preamble mode, you find a preamble, so you consume
> all items up to the end of that preamble, and set your state to "pass
> through", and then return from general_work. Before GNU Radio calls you
> next time, it will ask forecast() how many input items you need. Forecast
> always says it needs payload_length items, so at the point where work is
> actually called in "pass through" mode, you *should* have at least
> payload_length input items; let your block consume and produce these items,
> switch to "search preamble mode", and return.
>
>
>  Even worse, a stream of samples are coming continuously from a previous
> block.
>
> Lucky you! You have GNU Radio, which makes sure there's only one instance
> of your general_work being run at once, and presenting you with all the
> items you did not consume in the previous general_work calls.
>
>
>  Will it be helpful if I have some very long buffer in a block? I don't
> think it works since `noutput_items` is always smaller than `ninput_items`
> every time the block runs `general_work()`.
>
> That's not generally the case. It might be the case here, but that simply
> means that the downstream block isn't consuming the whole buffer, or your
> upstream items are larger, or your upstream block is just much faster at
> producing items than you and your downstream blocks are at consuming them.
>
> If you just try to rely on GNU Radio's buffers, you would be safe from
> something like buffer overflows happening -- GNU Radio will only call the
> upstream's general_work function if there is enough space in its output
> buffer (which is your input buffer).
>
> Personally, I think what you're doing is a complicated task, so I have a
> lot of respect for the effort you're putting into this.
> I'd try to avoid the complexity by *not* doing this in one block -- use a
> preamble correlator to mark the beginning of your frame with a stream tag.
> Then, use a state-machine block to only copy the payload_length items after
> such a tag (a whole payload at a time), adding a tag on the first item
> containing the length of the payload as long:
> I mentioned above there's an advantage to passing the whole payload at
> once; what you have when you have a length tag on the first item of
> contigous packet items is a tagged stream. Tagged stream blocks are a GNU
> Radio concept dedicated to processing packeted data, in which work()
> methods are always called with the whol

[Discuss-gnuradio] Diagnosing the cause of D's

[Richard Bell]

Hi all,

I need some help determining the cause of D's being displayed from my N210
device. I know it means GNU Radio is not consuming the samples from
my laptops Ethernet socket buffer fast enough, causing the USRP to overflow
it.

What I would like to do now, is learn how to monitor performance such that
I can figure out which part of my receiver is the bottleneck, so I can
focus on optimizations there. I can't lower the sample rate anymore,
because I'm already at the minimum rate the USRP requires (320k).

Would someone recommend a next course of action and tools I should download
to proceed?

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

Re: [Discuss-gnuradio] Diagnosing the cause of D's

[Johnathan Corgan]

On Fri, May 29, 2015 at 9:07 AM, Richard Bell 
wrote:


> What I would like to do now, is learn how to monitor performance such that
> I can figure out which part of my receiver is the bottleneck, so I can
> focus on optimizations there. I can't lower the sample rate anymore,
> because I'm already at the minimum rate the USRP requires (320k).
>
> Would someone recommend a next course of action and tools I should
> download to proceed?
>

There are many potential sources of problems that can result in overflow
from the USRP. Some common ones:

- Insufficient network stack buffering in the OS. Increasing this, however,
may just be masking the real problem, and at the data rate you are
describing, is unlikely the issue.

- One of the blocks in the flowgraph is exceeding the CPU resources
available in a single core.  While all GNU Radio blocks run in their own
threads and area scheduled by the OS onto as many cores as are available,
due to their sequential data dependencies, a single "slow" block can become
the rate-setting portion of the flowgraph.  Normally, you always want the
hardware to have this role.

- OS operations like periodic file system flushing can often consume CPU
and I/O bandwidth that competes with the flowgraph.  This is made much
worse if you are writing to disk as a result of the flowgraph processing.

A coarse view of the flowgraph resource usage (CPU, etc.) can be had with a
thread and core aware tool like "htop".  This will quickly show if a single
block/thread has become a CPU bottleneck.

A more granular view can be seen with the "perf" tool available in the
linux-tools package. This allows profiling CPU usage by function and can
identify hot spots for further optimization.

Finally, it might help to understand if the overflow events are "a few
every so often", or continuous.

-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
Intro to SDR Classes - June 4-5, Columbia MD, June 29-30, El Segundo, CA
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Wire format: using 8-bit (sc8) vs using 16-bit (sc16) resolution to gnu radio

[Nick Kara]

Hi, i am using usrp N200 and i set to gnu radio the wire format as either
16-bit -> sc16
or 8-bit ->sc8 and host format fc32(complex float) when i use
a) sc16 the power in the window where i see the spectrum is at -110 dB or
-100 dB, without transmitter sending data (so i see only noise)
b) sc8 the power in the window where i see the spectrum is at -80 db,
without transmitter sending data (so i see only noise as before)

Any ideas why i have a bigger starting power in 8-bit? It is -80 dB again
-110 dB.

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

Re: [Discuss-gnuradio] Wire format: using 8-bit (sc8) vs using 16-bit (sc16) resolution to gnu radio

[Martin Braun]

On 29.05.2015 12:53, Nick Kara wrote:
> Hi, i am using usrp N200 and i set to gnu radio the wire format as
> either 16-bit -> sc16
> or 8-bit ->sc8 and host format fc32(complex float) when i use
> a) sc16 the power in the window where i see the spectrum is at -110 dB
> or -100 dB, without transmitter sending data (so i see only noise)
> b) sc8 the power in the window where i see the spectrum is at -80 db,
> without transmitter sending data (so i see only noise as before) 
> 
> Any ideas why i have a bigger starting power in 8-bit? It is -80 dB
> again -110 dB.

Hey Nick,

it's all kind of arbitrarily scaled anyway (meaning that the absolute
value, 80 vs 110 is not very meaningful). So this is just an artifact of
how ADC bits are mapped onto the sc8 bits, and then the scaling. It does
not mean you're receiving more power or anything like that.


M

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

Re: [Discuss-gnuradio] What if noutput_itmes is too short?

[Marcus Müller]

Hi Jeon,

On 05/29/2015 05:25 PM, Jeon wrote:
> As I understand, if I consume(0, n), where n is less than
> ninput_items, then only n samples at the front of input_items[] are
> consumed and unconsumed part remains. And then, at the next call of
> general_work(), incoming samples are appended at the end of
> input_item[]. Is this right?
yes :)
>
> If it is right, I can get a single whole payload by not consuming
> input samples after some time passed...
you should always consume as many samples as possible to keep the flow
graph running; hence my recommendation to implement the forecast in a
manner that guarantees that your work will only be called with "enough"
input.
> However, I am still doubtful that input_items[] will not be appended
> as I think since output buffer at the previous block isn't cleared
> enough as `consume()` is not called.
the output buffer is completely independent from consume(); space in the
output buffer gets freed as soon as the downstream block calls
consume(), and gets filled by the amount you produce().
>
> Well... Does `forecast()` which you've mentioned make the previous
> block can send more streams and the current block can received them?
No, forecast is just the method that GNU radio calls to ask "hey, block!
If I want you to produce x items, how much input would you need?".
In your case, the honest answer for any x>0 would be "I need a whole
payload length of items if I should produce anything".
If you call set_output_multiple(payload_length), you will be guaranteed
enough space for at least one payload per general_work() call.

> So far, I understand `forecast()` acts as just a blocker unless enough
> samples are given.
It's more of a way of telling GNU Radio what to expect from your block.
>
> In the developing stage, I am using fixed length payload. But, I want
> to make it work with arbitrary length (but not too long).
In that case, use a forecast() that adjusts the returned length as soon
as your block knows how long the payload will be -- forecast() is really
just a hint for GNU Radio, so it doesn't hurt if it's not 100% accurate
(i.e. you produce less than what you've "promised" in forecast).

Best regards,
Marcus
> On Fri, May 29, 2015 at 9:52 PM Marcus Müller
> mailto:marcus.muel...@ettus.com>> wrote:
>
> Hi Jeon,
>
>
>
> On 05/29/2015 01:46 PM, Jeon wrote:
>> I am trying to remove `preamble` and `start frame delimiter` from
>> a frame and only the payload will be passed to the next block.
>>
>> While in debugging, `ninput_items` is 7742, and `noutput_items`
>> is 4096, for instance. An offset where the frame starts is 790.
>>
>> Simple calculation gives me that 7742 - 790 = 6952 samples should
>> be passed to the next block. But output space given is only 4096.
>> Thus, I can only pass 4096 samples and 6952 - 4096 = 2856 samples
>> will be discarded. But, I need them to be passed, too.
>
> There's no reason not to pass through your payload in parts, if
> you implement a state machine with a counter for remaining items
> to pass through in your block.
> However, there's an advantage to waiting for the whole payload to
> be on your input at once, which I'll explain further down.
> Does your payload always have the same length? In that case, your
> forecast should always demand payload_length input items to
> produce any amount of output items -- that way, you can make sure
> that at *one point*, you get the whole payload into your input buffer.
>
> No matter what you really do, you will need to use a state machine
> of some kind.
> In your case, that's comparatively easy: Just check, at the
> beginning of each general_work call, whether you're in
> pass-through mode, or in "search preamble mode", etc, and let your
> work act based upon that. For example, assume you're in search
> preamble mode, you find a preamble, so you consume all items up to
> the end of that preamble, and set your state to "pass through",
> and then return from general_work. Before GNU Radio calls you next
> time, it will ask forecast() how many input items you need.
> Forecast always says it needs payload_length items, so at the
> point where work is actually called in "pass through" mode, you
> *should* have at least payload_length input items; let your block
> consume and produce these items, switch to "search preamble mode",
> and return.
>
>>
>> Even worse, a stream of samples are coming continuously from a
>> previous block.
> Lucky you! You have GNU Radio, which makes sure there's only one
> instance of your general_work being run at once, and presenting
> you with all the items you did not consume in the previous
> general_work calls.
>
>>
>> Will it be helpful if I have some very long buffer in a block? I
>> don't think it works since `noutput_items` is always smaller than
>> `ninput_items` every time the block ru

Re: [Discuss-gnuradio] Diagnosing the cause of D's

[Marcus Müller]

Hi Richard,

320kS is not the minimal rate; if I'm not mistaken it's 100MHz/512.

Ds are relatively serious, and I've rarely seen them: The typical "your
system is too slow" results in "O"verflows; typically, you see "D" if
UHD starts wondering where the sample packet n disappeared to, after
receiving n-1 followed by n+1 (or so).

What's your ethernet hardware? (If on linux, "lspci | grep -i ether")
We've had some grief caused by USB3-to-ethernet-adapters which seemed to
take delight in confusing at least UHD, its users and a significant part
of its support team by randomly reordering packets on a direct link.
Also, there's a single Intel Gigabit Ethernet controller that comes
directly from hell, but it's becoming rarer in the wild every day.

Best regards,
Marcus



On 05/29/2015 06:07 PM, Richard Bell wrote:
> Hi all,
>
> I need some help determining the cause of D's being displayed from my
> N210 device. I know it means GNU Radio is not consuming the samples
> from my laptops Ethernet socket buffer fast enough, causing the USRP
> to overflow it.
>
> What I would like to do now, is learn how to monitor performance such
> that I can figure out which part of my receiver is the bottleneck, so
> I can focus on optimizations there. I can't lower the sample rate
> anymore, because I'm already at the minimum rate the USRP requires
> (320k).
>
> Would someone recommend a next course of action and tools I should
> download to proceed?
>
> Appreciated,
> Rich
>
>
> ___
> 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] Diagnosing the cause of D's

[Marcus D. Leech]

On 05/29/2015 02:13 PM, Marcus Müller wrote:

Hi Richard,

320kS is not the minimal rate; if I'm not mistaken it's 100MHz/512.

Ds are relatively serious, and I've rarely seen them: The typical 
"your system is too slow" results in "O"verflows; typically, you see 
"D" if UHD starts wondering where the sample packet n disappeared to, 
after receiving n-1 followed by n+1 (or so).


What's your ethernet hardware? (If on linux, "lspci | grep -i ether")
We've had some grief caused by USB3-to-ethernet-adapters which seemed 
to take delight in confusing at least UHD, its users and a significant 
part of its support team by randomly reordering packets on a direct 
link. Also, there's a single Intel Gigabit Ethernet controller that 
comes directly from hell, but it's becoming rarer in the wild every day.


Best regards,
Marcus

The notorious Intel NIC is the 82579LM.   It drops packets, even at low 
load.  It's a FIFO control bug that they couldn't ever fix...





On 05/29/2015 06:07 PM, Richard Bell wrote:

Hi all,

I need some help determining the cause of D's being displayed from my 
N210 device. I know it means GNU Radio is not consuming the samples 
from my laptops Ethernet socket buffer fast enough, causing the USRP 
to overflow it.


What I would like to do now, is learn how to monitor performance such 
that I can figure out which part of my receiver is the bottleneck, so 
I can focus on optimizations there. I can't lower the sample rate 
anymore, because I'm already at the minimum rate the USRP requires 
(320k).


Would someone recommend a next course of action and tools I should 
download to proceed?


Appreciated,
Rich


___
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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Integration of python's time.time() and work() calls

[Anil Kumar Yerrapragada]

Hi Marcus,

Thanks for the explanation, it is very clear.

But is there a way to keep track of time elapsed across *consecutive* work
calls?

Like I said in the first post in this thread, if I have a sliding window
based energy detect. Samples keep coming in, but at some point I will have
to say, right I have enough samples, let me start sliding my window now.

My algorithm is, as long signal energy (or power) in each window is less
than a threshold, do nothing and keep sliding. The moment power exceeds
threshold for the first time, I want to start measuring time. I need to see
how many windows I'm able to slide in the next let's say, 10 milliseconds
(because I expect that the actual signal transmission( by which i mean not
incoming samples, but *useful* samples) is to last for that long). As a
hypothetical example, let's say by 7 milliseconds I've reached the end of
the buffer.

My understanding is that by calling forecast, I am effectively creating an
an imaginary (?) array of that many samples to process. I may be getting
many 100s of samples, but if my forecast says only 50 should dealt with in
each work call, then that's how many will be available.

If my understanding is correct, once I reach the end of this imaginary
array, the next set of samples come in (as per forecast) and work is called
again. My question is how do I make this next work call aware of this
concept of time and that 3 milliseconds were unaccounted for in the last
call?

Is the solution simply to not limit the number of samples in each work call
i.e., not mess around with the forecast function at all?

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

Re: [Discuss-gnuradio] Integration of python's time.time() and work() calls

[Marcus Müller]

Hi Anil,

On 05/29/2015 09:07 PM, Anil Kumar Yerrapragada wrote:
> Hi Marcus, 
>
> Thanks for the explanation, it is very clear. 
>
> But is there a way to keep track of time elapsed across *consecutive*
> work calls?
well, you have the nitems_read() method, which, assuming you have a
constant sampling rate coming from some ADC hardware is directly
proportional to time.
>
> Like I said in the first post in this thread, if I have a sliding
> window based energy detect. Samples keep coming in, but at some point
> I will have to say, right I have enough samples, let me start sliding
> my window now. 
>
Then you should make it clear that you need that many samples. Override
the forecast() method to give GNU Radio a hint of how many samples you
need.
Don't consume items until you processed them.
> My algorithm is, as long signal energy (or power) in each window is
> less than a threshold, do nothing and keep sliding. The moment power
> exceeds threshold for the first time, I want to start measuring
> time. I need to see how many windows I'm able to slide in the next
> let's say, 10 milliseconds (because I expect that the actual signal
> transmission( by which i mean not incoming samples, but *useful*
> samples) is to last for that long). As a hypothetical example, let's
> say by 7 milliseconds I've reached the end of the buffer.
You've said that -- still, wall time has no meaning in GNU Radio, and
you should just go by the number of samples.
>
> My understanding is that by calling forecast,
you don't call forecast, you implement it.
> I am effectively creating an an imaginary (?) array of that many
> samples to process.
No. GNU Radio calls your block's forecast to ask your block how much
input it needs to produce a given amount of output. There's no data
involved at this point.
> I may be getting many 100s of samples, but if my forecast says only 50
> should dealt with in each work call, then that's how many will be
> available.
not exactly. Forecast gets called as a question. Your block is asked
"I'd like to ask you to produce 512 items. How much input do you need?".
If your block then says "I need 400 items", no matter for how many items
GNU Radio asks, GNU Radio will first try to reduce the number of items
it asks for, and then just stop asking until it has more input items.
>
> If my understanding is correct, once I reach the end of this imaginary
> array, the next set of samples come in (as per forecast) and work is
> called again. My question is how do I make this next work call aware
> of this concept of time and that 3 milliseconds were unaccounted for
> in the last call?
>
There's no imaginary array. Never wait anywhere in GNU Radio, especially
not by 3ms "wall clock time". Let the scheduler decide when and whether
to call your work function.

> Is the solution simply to not limit the number of samples in each work
> call i.e., not mess around with the forecast function at all?
You don't limit the number, you tell GNU Radio to supply at least a
specific amount of input items for a specific amount of output items.
Again, there's a guided tutorial chapter on this topic [1].

Best regards,
Marcus

[1]
https://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorial_GNU_Radio_in_C++#431-Specific-functions-related-to-block
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Problem with volk and fftw memory alignment

[djch-gnuradio]

I've been trying out the (bleeding edge) corr_est() code and the 
test_corr_est.grc sometimes segvs. Not repeatable, won't crash under gdb :-) 
From a core file, it's crashing loading the first element of aVector in 
volk_32fc_x2_multiply_32fc_a_avx
instruction is vmovaps (%eax),%ymm1where eax is 0x8b8b590.

My CPU supports the 256bit AVX instructions, and I believe such data needs to 
be 256bit=32 byte aligned. EAX here isn't. Looking at the backtrace, it's 
crashing in fft_filter_ccc::filter, where the d_fwdfft is generated from 
fft::fft_complex

In turn this creates d_inbuf by calling fftwf_malloc. I believe this only 
guarantees 16 byte alignment. (I'm on fftw3.3.4, on a 32 bit Linux 3.18.1, CPU 
Intel i5-3470)

As we move to use volk and the fast SIMD, should the code in fft.cc (and 
perhaps other places) move to using a volk memory allocator to get the right 
alignment, rather than fftwf_malloc?

I'm on gentoo, so I could fix the source to fftwf_malloc to return 32 byte 
aligned, but that's not a general solution. 

I'm not sure how I should report this issue, please pass on my report if 
there's a better place to discuss such things
-- 
 G8SQH


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

Re: [Discuss-gnuradio] How to start and stop recording without exiting the flowgraph

[Murray Thomson]

Hi,

I tried to follow Carl's suggestion to record a wav file but it didn't work
for me. The first time I change the check box the wav file sink will stop
working forever. File sinks works fine. Will Martin's suggestion work for
wav files or does anyone have another suggestion to record wav files only
when the checkbox is enabled?
I've attached my flowgraph.

Cheers,
Murray

2015-05-26 22:40 GMT+01:00 Carl Olsson :

> Thank you for the answer.
> I think I found however that the selector block and a check button is
> already doing what I needed.
>
> Cheers,
>
> Carl
>
> On 25 May 2015 at 02:14, Martin Braun  wrote:
>
>> On 05/24/2015 06:46 PM, Carl Olsson wrote:
>> > Hi all,
>> >
>> > I would like to use two filesink blocks to record signals from two
>> > USRP:s with MIMO Cable. I am interested in the phase offset of an
>> > incoming signal so I first need to calibrate and then start recording. I
>> > haven't found how this could be done in an easy way, does anyone have
>> > any ideas?
>> >
>> > To clarify:
>> > I would like to start my flowgraph then when I press a button in the GUI
>> > start recording and then press the button again and stop recording.
>>
>> Write a small Python block that takes a setter, then input a button
>> state through a QT selector. This block will only allow samples flowing
>> through when you input a certain state.
>>
>> Cheers,
>> M
>>
>>
>> ___
>> 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
>
>


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

Re: [Discuss-gnuradio] Integration of python's time.time() and work() calls

[Anil Kumar Yerrapragada]

Hi Marcus,

Thank you for your patient replies. Last question.

>>Your block is asked "I'd like to ask you to produce 512 items. How much
input do you need?".
>>If your block then says "I need 400 items",

This means that for the block to output 512 items it needs 400 items in the
input.

>>no matter for how many items GNU Radio asks,

What number is this? Isn't it the block that asks for items?

Do you mean GNURadio will first assume that the block needs some arbitrary
number of items in the input, say 1000 but after forecast call if the block
says it only needs 400, then GNURadio reduces the number to 400, look for
and if available, provide 400 items to the block? Is that it?


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

Re: [Discuss-gnuradio] What if noutput_itmes is too short?

[Sylvain Munaut]

Hi,

> As I understand, if I consume(0, n), where n is less than ninput_items, then
> only n samples at the front of input_items[] are consumed and unconsumed
> part remains. And then, at the next call of general_work(), incoming samples
> are appended at the end of input_item[]. Is this right?
>
> If it is right, I can get a single whole payload by not consuming input
> samples after some time passed...

Not really. Because the buffers are allocated only once at the start
and not resized and not really under your control.

So if you leave the sample in there, and the buffer fills up and you
still don't have a full payload, the graph will stall forever.
It's annoying and a pattern that comes up quite often but it's the way
it works ATM.


Cheers,

Sylvain

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