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
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
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
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
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
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,-
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
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
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
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
> 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
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
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
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
14 matches
Mail list logo