Re: [Discuss-gnuradio] Saving GNURadio flowgraph as vector graphics

[Dan CaJacob]

Try converting the png to a vector format first, but yes, a native vector
format would be nice.

On Wed, Nov 16, 2016 at 1:57 PM Suman Bhunia  wrote:

> Hello,
>
> I want to include a flowgraph in my paper. When I save it as png, the
> picture becomes little blurry in the final pdf version. I was wondering
> if I could save the flowgraph in vector graphics format such as eps,
> svg, etc.
>
> Thanks,
> Suman
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] Bug in GR runtime related to lock/unlock and tag propagation

[Johnathan Corgan]

On Wed, Nov 16, 2016 at 10:55 AM, Eugene Grayver 
wrote:

> I came across a nasty bug in the runtime.  It has something to do with the
> tag pruning code after a flowgraph is reconfigured.  My guess is that some
> counter is not being reset, even though the output buffer is reset.  It is
> easy to demonstrate by hooking up a usrp_source to tag_debug.  usrp_source
> inserts tags but they are not seen by the tag_debug (after the first time).
>
​It's really helpful that you provide a script that helps us replicate the
problem.  Can you report this on our Github issue tracker?​

-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Tag propagaton bug in pack_k_bits_bb

[Johnathan Corgan]

On Wed, Nov 16, 2016 at 5:15 PM, Eugene Grayver 
wrote:

> I found a tag propagation bug in pack_k_bits_bb.  Example python file to
> demonstrate the bug is below.  This block takes every 2 bits and packs them
> into one output.  Thus, a tag on input 0 should come out on output 0, and
> tag on input 7 should come out on output 3.  However, as can be seen from
> this example, the second tag comes out on output 4.  This is probably due
> to the way sync_decimator does tag propagation: round(input_index /
> decimation).  However, that is NOT the correct approach for this block.
>

​It would be useful to report this as an issue on our Github tracker.

-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] debugging runtime errors

[Johnathan Corgan]

On Wed, Nov 16, 2016 at 1:56 PM, Tom Early  wrote:


> Maybe cmake should error out if it can't find swig. Or am I missing
> something in the big picture?
>

​It's entirely possible run GNU Radio as a pure C++ application wrapping
C++ native and OOT blocks; in those cases, we have the option to not bother
with compiling any of the SWIG/Python wrapper code.

However, if you're using a stock apt-get installed version of GNU Radio, it
should be pulling in the appropriate swig packages, so the error above is
unusual.

-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Tag propagaton bug in pack_k_bits_bb

[Eugene Grayver]

Hello,

I found a tag propagation bug in pack_k_bits_bb.  Example python file to 
demonstrate the bug is below.  This block takes every 2 bits and packs them 
into one output.  Thus, a tag on input 0 should come out on output 0, and tag 
on input 7 should come out on output 3.  However, as can be seen from this 
example, the second tag comes out on output 4.  This is probably due to the way 
sync_decimator does tag propagation: round(input_index / decimation).  However, 
that is NOT the correct approach for this block.

Eugene

---
from gnuradio import gr, blocks
import pmt
top = gr.top_block()
tag1 = gr.python_to_tag((0, pmt.intern('A'), pmt.PMT_NIL))
tag2 = gr.python_to_tag((7, pmt.intern('B'), pmt.PMT_NIL))
src = blocks.vector_source_b([0,]*10, tags=[tag1, tag2])
packer = blocks.pack_k_bits_bb(2)
dbg = blocks.tag_debug(gr.sizeof_char,'A')
top.connect(src, packer, dbg)
top.run()
--





Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274

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

Re: [Discuss-gnuradio] debugging runtime errors

[Tom Early]

Okay, my mistake. After more carefully reading the build output, I 
realized my system was missing swig. There was just a little, 
easy-to-miss comment about not finding swig buried in the "cmake .." output.


Maybe cmake should error out if it can't find swig. Or am I missing 
something in the big picture?


BTW, I'm using apt-installed gnuradio on a fresh install of ubuntu 16.10.

On 11/16/2016 10:25 AM, Tom Early wrote:
I would like to follow up a suggestion that my "AttributeError: 
'module' object has no attribute ..." runtime error is caused by an 
improperly linked OOT.


I am unsure how to do that. Can someone point me in the correct 
direction?


Thanks!






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

Re: [Discuss-gnuradio] PDUs in GNU Radio for UHD USRP Sink

[Collins, Richard]

Hey Sean,

Thanks for the heads up. I was just looking through the
pdu_to_tagged_stream block for debugging. I noticed the comment about
blocking, and wondered if a dedicated message handler would be a better
option than overloading "calculate_output_stream_length".

Thanks for the info about the tsb_tag_name... I was wondering if I should
use the PDU to Tagged Stream block before going into the USRP, and it seems
a common option to take.  Using the Tag Debug block after the PDU to Tagged
Stream block, I see that tx_sob, tx_time, and tx_eob pass through. I'll
test ASAP to see if the USRP Sink listens to these tags (now that it should
see them). If not, I'll try setting the tsb_tag_name to packet_len (which I
guess causes the usrp sink to ignore tx_sob, tx_eob, etc.).

Thanks again,

  - Rich

On Wed, Nov 16, 2016 at 11:23 AM, Sean Nowlan  wrote:

> I think you will have to write a custom block that is similar to the
> pdu_to_tagged_stream block, but doesn't inherit from tagged_stream_block to
> avoid the limitation on the number of samples that can be handled. Here's
> how I'd do it, but keep in mind I haven't tried this and you may get into
> trouble doing blocking waits within the work method.
> * Copy pdu_to_tagged_stream in an OOT project.
> * Inherit from source_block instead of tagged_stream_block.
> * Move the stuff that's in "calculate_output_stream_length" into the top
> of the work method body. It looks like this will do a blocking wait with a
> timeout to see if there is a PDU available on the queue. If not, it should
> return 0 items. Once a PDU is found, it stashes the PDU's metadata, data
> vector, and length.
> * At the seciton of the work method that copies tags, I suggest keeping
> that code since it will copy your PDU length. The downstream USRP sink
> should be configured with a tsb_tag_name argument matching the 'packet_len'
> field in your PDU's metadata.
> * At the bottom of the work method, write as many items of the data vector
> to the output as noutput_items allows, and then decrement the number of
> remaining items to write. Keep an index or pointer into your current buffer
> and increment that too. After one or more work calls you should have
> written the entire buffer to the output and you can go back to looking for
> PDU packets on the input port.
>
> Hope this helps.
>
> Sean
>
> You'd have to add a message handler that stashes
>
> work
>
> On Thu, Nov 10, 2016 at 9:07 PM, Collins, Richard <
> richard.coll...@axenterprize.com> wrote:
>
>> Hello,
>>
>> I'm having trouble figuring out how to correctly send PDUs to the UHD
>> USRP Sink. It's my understanding (mostly from [1] and [2]) that you can
>> send a PDU with
>>
>>- a dictionary car containing "tx_sob" set to PMT_T, (and maybe
>>"tx_time" formatted according to notes in [2] or in the source code), and
>>- a uniform vector cdr containing complex32 samples to send.
>>
>> What I've done is make a block that accepts a stream of samples tagged by
>> a previous block (using stream tags), and saves them off to a std::vector
>> between the start and end tags. This part works as expected. Once this
>> vector (or "pkt_buffer") is full, other samples are ignored and the
>> transmission half of the code in this custom block is able to run. It uses
>> usrp->get_time_now() to check to see if some time has elapsed, and if so,
>> carves up the internal "pkt_buffer" vector into PDUs of the desired size
>> (e.g. a max of 512 samples long), and sends them out of the registered
>> message port. Externally, this port is connected to the "command" port of
>> the UHD USRP Sink block.
>>
>> I know these messages have a max size (I think of 4k samples), and it
>> seems to work best (e.g. without the flowgraph freezing freezing, or
>> uhd_usrp_source block taking up too much CPU of one core) when the size is
>> smaller (e.g. 512 samples).
>>
>> What happens though, as seen through captured samples from another SDR,
>> is the USRP will output nothing for a while (a little longer than the
>> expected length in time of my whole "packet" or set of PDUs). Then the USRP
>> will output what looks just like a carrier signal for the rest of the time
>> before the next burst of PDUs (I'm assuming from the Null Source feeding
>> into the UHD USRP Sink block's streaming "in" port, which must be connected
>> to something in GNU Radio).
>>
>> As a small side note, I don't get an error output except for a single U
>> per packet... it seems if I send too many PDUs (i.e. more than the first,
>> second to last, and the last), I'll get a "U" after a whole set of PDUs is
>> sent. I don't think that's a problem though.
>>
>> I've checked the output of this block with the message debug block, and
>> it seems that the correct samples are sent in the expected order.
>>
>> An example of what I'm trying to do (in C++) can be found here:
>> http://pastebin.com/uyNTkFmU
>> Documentation Used:
>>   [1] - 

[Discuss-gnuradio] Saving GNURadio flowgraph as vector graphics

[Suman Bhunia]

Hello,

I want to include a flowgraph in my paper. When I save it as png, the 
picture becomes little blurry in the final pdf version. I was wondering 
if I could save the flowgraph in vector graphics format such as eps, 
svg, etc.


Thanks,
Suman


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

[Discuss-gnuradio] Bug in GR runtime related to lock/unlock and tag propagation

[Eugene Grayver]

Hello,


I came across a nasty bug in the runtime.  It has something to do with the tag 
pruning code after a flowgraph is reconfigured.  My guess is that some counter 
is not being reset, even though the output buffer is reset.  It is easy to 
demonstrate by hooking up a usrp_source to tag_debug.  usrp_source inserts tags 
but they are not seen by the tag_debug (after the first time).


Here's a full python example script.




from gnuradio import gr, blocks, uhd
import time
top = gr.top_block()
src = uhd.usrp_source('', uhd.stream_args('fc32'))
dbg = blocks.tag_debug(gr.sizeof_gr_complex,'A')
top.connect(src, dbg)
top.start()
for idx in range(10):
time.sleep(5)
top.lock()
top.disconnect(src, dbg)
# Tags are lost whether we reuse the same dbg or create a new one
#dbg = blocks.tag_debug(gr.sizeof_gr_complex,'A%d' % idx)
top.connect(src, dbg)
top.unlock()

top.stop()
top.wait()
---



Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274

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

[Discuss-gnuradio] Probing value when no items

[David Halls]

Hi guys,


I am showing EVM (a block we have written) in a text box using a probe signal, 
in an OFDM system based on MB's OFDM example.


this works fine when packets are being received, but I would like to show 0 
when no packets are received (no items coming through HPD), rather than just 
the EVM calculated based on the last *received* packet.


Thanks for your help!

David



NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] PDUs in GNU Radio for UHD USRP Sink

[Collins, Richard]

Got it!

Thanks to a little guidance from ee.k...@gmail.com and some debugging, I
found out that the dictionary in my PDU appeared as empty. That's because I
was doing things like:
pmt::dict_add(d_pdu_meta, tx_sob, pmt::PMT_T);
instead of:
d_pdu_meta = pmt::dict_add(d_pdu_meta, tx_sob, pmt::PMT_T);

Glad it was something this small. Easy to overlook!

 - Rich

On Thu, Nov 10, 2016 at 9:07 PM, Collins, Richard <
richard.coll...@axenterprize.com> wrote:

> Hello,
>
> I'm having trouble figuring out how to correctly send PDUs to the UHD USRP
> Sink. It's my understanding (mostly from [1] and [2]) that you can send a
> PDU with
>
>- a dictionary car containing "tx_sob" set to PMT_T, (and maybe
>"tx_time" formatted according to notes in [2] or in the source code), and
>- a uniform vector cdr containing complex32 samples to send.
>
> What I've done is make a block that accepts a stream of samples tagged by
> a previous block (using stream tags), and saves them off to a std::vector
> between the start and end tags. This part works as expected. Once this
> vector (or "pkt_buffer") is full, other samples are ignored and the
> transmission half of the code in this custom block is able to run. It uses
> usrp->get_time_now() to check to see if some time has elapsed, and if so,
> carves up the internal "pkt_buffer" vector into PDUs of the desired size
> (e.g. a max of 512 samples long), and sends them out of the registered
> message port. Externally, this port is connected to the "command" port of
> the UHD USRP Sink block.
>
> I know these messages have a max size (I think of 4k samples), and it
> seems to work best (e.g. without the flowgraph freezing freezing, or
> uhd_usrp_source block taking up too much CPU of one core) when the size is
> smaller (e.g. 512 samples).
>
> What happens though, as seen through captured samples from another SDR, is
> the USRP will output nothing for a while (a little longer than the expected
> length in time of my whole "packet" or set of PDUs). Then the USRP will
> output what looks just like a carrier signal for the rest of the time
> before the next burst of PDUs (I'm assuming from the Null Source feeding
> into the UHD USRP Sink block's streaming "in" port, which must be connected
> to something in GNU Radio).
>
> As a small side note, I don't get an error output except for a single U
> per packet... it seems if I send too many PDUs (i.e. more than the first,
> second to last, and the last), I'll get a "U" after a whole set of PDUs is
> sent. I don't think that's a problem though.
>
> I've checked the output of this block with the message debug block, and it
> seems that the correct samples are sent in the expected order.
>
> An example of what I'm trying to do (in C++) can be found here:
> http://pastebin.com/uyNTkFmU
> Documentation Used:
>   [1] - http://gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__sink.html
>   [2] - http://gnuradio.org/doc/doxygen/page_uhd.html#uhd_
> command_syntax_cmds
>   [3] - http://gnuradio.org/doc/doxygen/page_pmt.html
>   [4] - http://gnuradio.org/doc/doxygen/page_msg_passing.html
> Examples found:
>   [5] - https://github.com/bastibl/gr-foo/blob/master/lib/packet_
> pad_impl.cc helped, but he's using stream tags, not Asynchronous Message
> passing
>   [6] - some examples in uhd/host/examples/ and
> gnuradio/gr-uhd/examples/c++/ but mostly for testing uhd function calls to
> get/set gps time.
>
> It's been suggested a couple times to use asynchronous message passing
> instead of tagged streams when I've asked over the past year or so, and I
> see why from an old post from Tim O'Shea's blog that shows the differences
> in performance. I just don't know how to use his eventstream or other
> underlying gr-vt blocks, and would like to rely on as few OOT modules as
> possible. I've found a few examples where tagged streams are used, but not
> any with PDUs.
>
> I've made a block almost a year ago (my first one, actually) which used
> PDUs in Python, but I found that I ended up using a PDU to Tagged Stream
> block before the UHD USRP Sink. That was ok for that instance; but now I've
> got to send a relatively large set (>4k) of samples at a specific time.
>
> Any help or guidance is appreciated! Hopefully I'm just missing something
> small or obvious.
>
> Thanks,
>
> Richard Collins
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] PDUs in GNU Radio for UHD USRP Sink

[Sean Nowlan]

I think you will have to write a custom block that is similar to the
pdu_to_tagged_stream block, but doesn't inherit from tagged_stream_block to
avoid the limitation on the number of samples that can be handled. Here's
how I'd do it, but keep in mind I haven't tried this and you may get into
trouble doing blocking waits within the work method.
* Copy pdu_to_tagged_stream in an OOT project.
* Inherit from source_block instead of tagged_stream_block.
* Move the stuff that's in "calculate_output_stream_length" into the top of
the work method body. It looks like this will do a blocking wait with a
timeout to see if there is a PDU available on the queue. If not, it should
return 0 items. Once a PDU is found, it stashes the PDU's metadata, data
vector, and length.
* At the seciton of the work method that copies tags, I suggest keeping
that code since it will copy your PDU length. The downstream USRP sink
should be configured with a tsb_tag_name argument matching the 'packet_len'
field in your PDU's metadata.
* At the bottom of the work method, write as many items of the data vector
to the output as noutput_items allows, and then decrement the number of
remaining items to write. Keep an index or pointer into your current buffer
and increment that too. After one or more work calls you should have
written the entire buffer to the output and you can go back to looking for
PDU packets on the input port.

Hope this helps.

Sean

You'd have to add a message handler that stashes

work

On Thu, Nov 10, 2016 at 9:07 PM, Collins, Richard <
richard.coll...@axenterprize.com> wrote:

> Hello,
>
> I'm having trouble figuring out how to correctly send PDUs to the UHD USRP
> Sink. It's my understanding (mostly from [1] and [2]) that you can send a
> PDU with
>
>- a dictionary car containing "tx_sob" set to PMT_T, (and maybe
>"tx_time" formatted according to notes in [2] or in the source code), and
>- a uniform vector cdr containing complex32 samples to send.
>
> What I've done is make a block that accepts a stream of samples tagged by
> a previous block (using stream tags), and saves them off to a std::vector
> between the start and end tags. This part works as expected. Once this
> vector (or "pkt_buffer") is full, other samples are ignored and the
> transmission half of the code in this custom block is able to run. It uses
> usrp->get_time_now() to check to see if some time has elapsed, and if so,
> carves up the internal "pkt_buffer" vector into PDUs of the desired size
> (e.g. a max of 512 samples long), and sends them out of the registered
> message port. Externally, this port is connected to the "command" port of
> the UHD USRP Sink block.
>
> I know these messages have a max size (I think of 4k samples), and it
> seems to work best (e.g. without the flowgraph freezing freezing, or
> uhd_usrp_source block taking up too much CPU of one core) when the size is
> smaller (e.g. 512 samples).
>
> What happens though, as seen through captured samples from another SDR, is
> the USRP will output nothing for a while (a little longer than the expected
> length in time of my whole "packet" or set of PDUs). Then the USRP will
> output what looks just like a carrier signal for the rest of the time
> before the next burst of PDUs (I'm assuming from the Null Source feeding
> into the UHD USRP Sink block's streaming "in" port, which must be connected
> to something in GNU Radio).
>
> As a small side note, I don't get an error output except for a single U
> per packet... it seems if I send too many PDUs (i.e. more than the first,
> second to last, and the last), I'll get a "U" after a whole set of PDUs is
> sent. I don't think that's a problem though.
>
> I've checked the output of this block with the message debug block, and it
> seems that the correct samples are sent in the expected order.
>
> An example of what I'm trying to do (in C++) can be found here:
> http://pastebin.com/uyNTkFmU
> Documentation Used:
>   [1] - http://gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__sink.html
>   [2] - http://gnuradio.org/doc/doxygen/page_uhd.html#uhd_
> command_syntax_cmds
>   [3] - http://gnuradio.org/doc/doxygen/page_pmt.html
>   [4] - http://gnuradio.org/doc/doxygen/page_msg_passing.html
> Examples found:
>   [5] - https://github.com/bastibl/gr-foo/blob/master/lib/packet_
> pad_impl.cc helped, but he's using stream tags, not Asynchronous Message
> passing
>   [6] - some examples in uhd/host/examples/ and
> gnuradio/gr-uhd/examples/c++/ but mostly for testing uhd function calls to
> get/set gps time.
>
> It's been suggested a couple times to use asynchronous message passing
> instead of tagged streams when I've asked over the past year or so, and I
> see why from an old post from Tim O'Shea's blog that shows the differences
> in performance. I just don't know how to use his eventstream or other
> underlying gr-vt blocks, and would like to rely on as few OOT modules as
> possible. I've found a few examples where tagged streams are 

[Discuss-gnuradio] debugging runtime errors

[Tom Early]

I would like to follow up a suggestion that my "AttributeError: 'module' 
object has no attribute ..." runtime error is caused by an improperly 
linked OOT.


I am unsure how to do that. Can someone point me in the correct direction?

Thanks!


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