Re: [Discuss-gnuradio] Stream to PDU - Guaranteed to not lump tags?

2018-01-10 Thread Dave NotTelling
That does help! Thanks Michael :) On Wed, Jan 10, 2018 at 9:10 PM, Michael Dickens wrote: > Hi Dave - The tagged stream -> PDU block will generate exactly 1 PDU per > call to work. In your example, it is possible that all 3 of the PDUs will > end up being in the stream, but, because of the way

Re: [Discuss-gnuradio] Stream to PDU - Guaranteed to not lump tags?

2018-01-10 Thread Michael Dickens
Hi Dave - The tagged stream -> PDU block will generate exactly 1 PDU per call to work. In your example, it is possible that all 3 of the PDUs will end up being in the stream, but, because of the way "tagged_stream_block" works, work() will be called with "ninput_items[0]" being just the value enter

Re: [Discuss-gnuradio] Stream to PDU - Guaranteed to not lump tags?

2018-01-10 Thread Dave NotTelling
Michael, Thanks for the response! Apologies for the unclear question. Here's another shot: Can one call to the work function yield multiple offsets from the `get_tags_in_range(0, nitems_read(0), nitems_read(0) + noutput_items)` call? With multiple offsets then that means there are multipl

Re: [Discuss-gnuradio] OFDM channel tap questions

2018-01-10 Thread Jeff Long
Hmm, that wasn't the whole answer. After reading the code a little more, it looks like the taps are a function of the sync symbols too, not just the channel. for (int i = loop_start; i < loop_end; i++) { if ((d_ref_sym[i-carr_offset] != gr_complex(0, 0))) { taps[i-carr_o

Re: [Discuss-gnuradio] OFDM channel tap questions

2018-01-10 Thread Jeff Long
Noise has some bias and structure when measured over a short period. You can see this on a FFT display, where larger transforms give you a smoother noise floor. You'll notice that the taps change randomly with every packet as the estimator adjusts to the noise. On 01/10/2018 04:59 PM, Edwin Li

[Discuss-gnuradio] OFDM channel tap questions

2018-01-10 Thread Edwin Li
Hi all, I run the example found in the ~/prefix/share/gnuradio/examples/digital/ofdm/rx_ofdm.grc. The ofdm signals can be decoded correctly. But I don't understand the channel taps. The channel taps are shown to be Key: ofdm_sync_chan_taps Value: #[(0,0) (0,0) (0,0) (0,0) (0,0) (0,0) (64.2159,-

Re: [Discuss-gnuradio] FM pre-emphasis and de-emphasis

2018-01-10 Thread Andy Walls
From: Richard Lamont Date: Wed, 10 Jan 2018 20:41:06 + > On 10/01/18 18:53, Andy Walls wrote: [snip] > > The filters stay within 0.1 dB of each other up through 5000 Hz, > but by > > then your tabular response has noticeably started to bend > upward. The > > difference between the two f

Re: [Discuss-gnuradio] FM pre-emphasis and de-emphasis

2018-01-10 Thread Richard Lamont
On 10/01/18 18:53, Andy Walls wrote: [snip] >> When working correctly, the amplitude/frequency response should be >> within, ideally, 0.1 dB of the values shown. I've shown values for >> both 75 and 50 microsecond time constants. >> >> Freq (Hz) Gain dB (75us) Gain dB (50us) >> >> 30

Re: [Discuss-gnuradio] Stream to PDU - Guaranteed to not lump tags?

2018-01-10 Thread Michael Dickens
Hi Dave - The tagged stream -> PDU block will look at for the provided tag string at the current 0 offset & if found then that's what the PDU data size (in items) will be [this is actually handled in the "tagged_stream_block" parent class]. If there are interim tags (within the output PDU size i

[Discuss-gnuradio] make test fails at qa_zeromq_pub [was "Re: [USRP-users] making the UHD"]

2018-01-10 Thread Michael Dickens
Hi Alejandra - Moving to the GR list since this is not really a USRP topic. Try "ctest -V -R qa_zeromq_pub" and see what it shows. There are a few GR tests that work intermittently & this might be one of them. Also might be something more involved, given the strange error printout compared to th

Re: [Discuss-gnuradio] FM pre-emphasis and de-emphasis

2018-01-10 Thread Andy Walls
> Date: Tue, 9 Jan 2018 00:32:41 + > From: Richard Lamont [snip] > Fair enough. I've just started playing with grc and did the usual FM > broadcast RX thing as my Hello World - and, as a former broadcast > engineer with pretty good ears - I immediately noticed that there was > far too much 't

[Discuss-gnuradio] Stream to PDU - Guaranteed to not lump tags?

2018-01-10 Thread Dave NotTelling
The wording of the title likely needs work, but the basic idea is this: - Suppose that I have a ZMQ message source that has arbitrarily sized vectors of some consistent type - I convert that over to a tagged stream, do some operations on it, then convert it back to a PDU - Assume f

Re: [Discuss-gnuradio] package 'gnuradio-fft' not found

2018-01-10 Thread Dave NotTelling
You are missing quite a few libs. The one that's causing your specific issue: -- Configuring gr-fec support... -- Dependency ENABLE_VOLK = ON -- Dependency Boost_FOUND = 1 -- Dependency ENABLE_GNURADIO_RUNTIME = ON -- Dependency ENABLE_GR_BLOCKS = ON -- Enabling gr-fec support. -- Ove

[Discuss-gnuradio] Poly Filter Bank for unfiltered signals

2018-01-10 Thread Sakthivel Velumani
Hi all, I want to use the pfb_clock_sync block to correct the timing delay in my received signal. The received signal in my case is not pulse shaped i.e no RRC or any filter is used at the transmitter side. In this case what should I give in the filter taps field of the pfb block? I tried all 1s