Re: [Discuss-gnuradio] SDRplay rewrite w/RSP2

The RSP1A and RSP2 work well for me using this code, and there are many improvements since my last post, so I'm looking for other people to help test it. Something along the lines of the following commands will allow installation and test using a temporary directory: git clone

Re: [Discuss-gnuradio] pmt.to_python behaves differently in console and in gnuradio

Nevermind.Problem was in my code creating the np.array over on the send side. Sorry to waste the bandwidth. -- Tom, N5EG On Mon, Jan 1, 2018 at 1:23 PM, Tom McDermott wrote: > > Hello, Happy New Year ! > > I am trying to use message passing in gnuradio maint

[Discuss-gnuradio] pmt.to_python behaves differently in console and in gnuradio

Hello, Happy New Year ! I am trying to use message passing in gnuradio maint branch, 3.7.11.1 (python 2.7 based) When just bringing up a command line window, starting python 2.7, importing gnuradio, numpy and pmt, the behavior I get (which agrees with the documentation): n =

Re: [Discuss-gnuradio] Serious bug in tag propagation with non-integer relative rate

(and if I'd actually read Andy's last post carefully ...) On 01/01/2018 01:32 PM, Jeff Long wrote: As Eugene suggests, the fractional resampler can be handled by doing a linear mapping from the input to the output of a single work call. Wouldn't this work with most or all blocks? There would

Re: [Discuss-gnuradio] Serious bug in tag propagation with non-integer relative rate

As Eugene suggests, the fractional resampler can be handled by doing a linear mapping from the input to the output of a single work call. Wouldn't this work with most or all blocks? There would also need to be an offset in order to handle history. Then, there wouldn't be a need to use higher

[Discuss-gnuradio] Boost 1.66.0 Compatibility: GNU Radio & Volk & UHD

In initial testing, Boost 1.66.0 is fully compatible with the current GNU Radio and Volk GIT master & current releases. There's an issue with UHD that has already been fixed in the GIT master, but the new boost otherwise seems to work with UHD & the backport to the latest release is very

Re: [Discuss-gnuradio] Serious bug in tag propagation with non-integer relative rate

I think the reason rate changes are difficult for tags is that the block executor tries to guess what a block is doing based on its long-term or static rate change. The block itself knows exactly how input items relate to output items, and maybe certain blocks need to provide more feedback

Re: [Discuss-gnuradio] noutput_items in every block

Hi Sakthivel - Short answers: The value can vary for each call; it is determined by the scheduler. I've provided more info below if you're curious. Cheers! - MLD Details: One way to think of your questions is to imagine the finite-length I/O buffers that hold the data between blocks, and note

Re: [Discuss-gnuradio] Serious bug in tag propagation with non-integer relative rate

Hi Marcus: On Sun, 2017-12-31 at 15:09 +, Müller, Marcus (CEL) wrote: > Hi Andy, hi Eugene > > Hm, coming back to an idea I had not so long ago: > > tag offset should not be 64bit unsihned integers only, but also have > a > 64 bit fractional part. > > That would not immediately solve the

[Discuss-gnuradio] noutput_items in every block

Hi all, I am new to GNU radio. I have this general doubt that when items are streamed from one block to another, how many input_items per port (consider a type general block) are passed when the work() function of the block is called each time? I guess this is handled by the GNU radio's scheduler