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

[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 "tagged_stream_block"
> works, work() will be called with "ninput_items[0]" being just the value
> entered for the tag representing any given PDU length, no more or less.
>
> This stated, it is possible to end up with multiple same-named tag offset
> values in the stream on the same item; I've seen this recently. There are
> also sometimes other tags within range on the stream. All of the tags that
> aren't removed as the provided length key will be added to the PDU as
> meta-data. This might be the source of your "multiple offset values"
> comment.
>
> Hope this helps! - MLD
>
> On Wed, Jan 10, 2018, at 8:32 PM, Dave NotTelling wrote:
>
>  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 multiple sets of
> PDUs (assuming that the stream was created from pdu_to_tagged_stream).
> Let's say for fun that there are 3 PDUs like the following (CAR, CDR):
>
>
>- ( {'pdu_len': 10, 'offset': 0, 'frame' : 1}, (0x00 0x00 0x00 0x00
>0x00 0x00 0x00 0x00 0x00 0x00) )
>- ( {'pdu_len': 10, 'offset': 10, 'frame' : 2}, (0x00 0x00 0x00 0x00
>0x00 0x00 0x00 0x00 0x00 0x00) )
>- ( {'pdu_len': 10, 'offset': 11, 'frame' : 3}, (0x00 0x00 0x00 0x00
>0x00 0x00 0x00 0x00 0x00 0x00) )
>
> What I'm curious about is whether or not a single call to work() will end
> up with tags for more than one of the PDUs above.  For instance, if the
> buffer for the block is large enough, would 20 samples get lumped in to a
> single call to work() resulting in say offset 0 and offset 10 both showing
> up in 'get_tags_in_range(0, nitems_read(0), nitems_read(0) +
> noutput_items)'?  This of course assumes that pdu_to_tagged_stream and
> tagged_stream_to_pdu both are set to use 'pdu_len' as the length tag.
>
>  I seem to remember having that very issue once.  I got multiple
> offset values in a work() function in the past.  Pretty sure I did at least
> O.o  Really, just curious if there is a guarantee somewhere deeper in the
> block code that ensures that can't happen.
>
>  As I write this I realize that this is a pretty easy thing to test
> out.  If it's still unclear, then I'll just do that and post results :)
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[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 entered for the tag representing
any given PDU length, no more or less.
This stated, it is  possible to end up with multiple same-named tag
offset values in the stream on the same item; I've seen this recently.
There are also sometimes other tags  within range on the stream. All of
the tags that aren't removed as the provided length key will be added to
the PDU as meta-data. This might be the source of your "multiple offset
values" comment.
Hope this helps! - MLD

On Wed, Jan 10, 2018, at 8:32 PM, Dave NotTelling wrote:
>  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 multiple sets of PDUs (assuming that the stream was created from
>> pdu_to_tagged_stream).  Let's say for fun that there are 3 PDUs like
>> the following (CAR, CDR):
>>  * ( {'pdu_len': 10, 'offset': 0, 'frame' : 1}, (0x00 0x00 0x00 0x00
>>0x00 0x00 0x00 0x00 0x00 0x00) )
>>  * ( {'pdu_len': 10, 'offset': 10, 'frame' : 2}, (0x00 0x00 0x00 0x00
>>0x00 0x00 0x00 0x00 0x00 0x00) )
>>  * ( {'pdu_len': 10, 'offset': 11, 'frame' : 3}, (0x00 0x00 0x00 0x00
>>0x00 0x00 0x00 0x00 0x00 0x00) )>> What I'm curious about is whether or 
>> not a single call to work() will
>> end up with tags for more than one of the PDUs above.  For instance,
>> if the buffer for the block is large enough, would 20 samples get
>> lumped in to a single call to work() resulting in say offset 0 and
>> offset 10 both showing up in 'get_tags_in_range(0, nitems_read(0),
>> nitems_read(0) + noutput_items)'?  This of course assumes that
>> pdu_to_tagged_stream and tagged_stream_to_pdu both are set to use
>> 'pdu_len' as the length tag.>  I seem to remember having that very issue 
>> once.  I got multiple
>  offset values in a work() function in the past.  Pretty sure I
>  did at least O.o  Really, just curious if there is a guarantee
>  somewhere deeper in the block code that ensures that can't
>  happen.> 
>  As I write this I realize that this is a pretty easy thing to
>  test out.  If it's still unclear, then I'll just do that and post
>  results :)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[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 multiple sets of
PDUs (assuming that the stream was created from pdu_to_tagged_stream).
Let's say for fun that there are 3 PDUs like the following (CAR, CDR):


   - ( {'pdu_len': 10, 'offset': 0, 'frame' : 1}, (0x00 0x00 0x00 0x00
   0x00 0x00 0x00 0x00 0x00 0x00) )
   - ( {'pdu_len': 10, 'offset': 10, 'frame' : 2}, (0x00 0x00 0x00 0x00
   0x00 0x00 0x00 0x00 0x00 0x00) )
   - ( {'pdu_len': 10, 'offset': 11, 'frame' : 3}, (0x00 0x00 0x00 0x00
   0x00 0x00 0x00 0x00 0x00 0x00) )

What I'm curious about is whether or not a single call to work() will end
up with tags for more than one of the PDUs above.  For instance, if the
buffer for the block is large enough, would 20 samples get lumped in to a
single call to work() resulting in say offset 0 and offset 10 both showing
up in 'get_tags_in_range(0, nitems_read(0), nitems_read(0) +
noutput_items)'?  This of course assumes that pdu_to_tagged_stream and
tagged_stream_to_pdu both are set to use 'pdu_len' as the length tag.


 I seem to remember having that very issue once.  I got multiple offset
values in a work() function in the past.  Pretty sure I did at least O.o
Really, just curious if there is a guarantee somewhere deeper in the block
code that ensures that can't happen.

 As I write this I realize that this is a pretty easy thing to test
out.  If it's still unclear, then I'll just do that and post results :)

Thanks!

On Wed, Jan 10, 2018 at 3:32 PM, Michael Dickens 
wrote:

> 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 in items), then they are just added as meta-data to the
> PDU. Each PDU is created independent of the other PDUs, and just 1 created
> per call to "work". Not sure if this is what you were looking to have
> answered; if not, please clarity. Cheers! - MLD
>
> On Wed, Jan 10, 2018, at 11:30 AM, Dave NotTelling wrote:
> > 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 for a second that several of the offsets in the tagged stream
> are very small (only say 10 samples each) and back to back
> >  * Is there a guarantee that each of the 10 sample offsets will result
> in a single PDU?
> >
> >Looking at the source of tagged_stream_to_pdu it seems that there is no
> check that multiple tag offsets arrived in a single call to work.  Or is
> that something that cannot happen?  Having a contract that no more than one
> offset can arrive at a single call to work would be really nice, but I
> imagine that doing so could cause some pretty serious performance issues.
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OFDM channel tap questions

[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_offset] = sym[i] / d_ref_sym[i-carr_offset];
}
  }

On 01/10/2018 06:19 PM, Jeff Long wrote:
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 wrote:

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,-3.65375) (47.2264,-42.4505) (8.44977,-62.8107) 
(-32.7931,-54.5247) (-59.9085,-21.3488) (-59.8031,23.3288) 
(-32.3382,55.4137) (9.05079,63.8184) (46.331,42.7923) 
(65.1778,2.83559) (51.1081,-38.6363) (15.815,-62.1237) 
(-27.1419,-57.8722) (-58.2753,-27.4043) (-62.3711,15.658) 
(-37.9986,51.1873) (3.2302,64.2116) (5.44772,5.36124) 
(6.75629,1.41069) (54.079,-33.4137) (2.19591,-6.12473) 
(-1.91544,-6.56722) (-5.87699,-3.166) (-6.83039,0.994718) 
(-4.49682,5.42143) (-0.363706,6.79664) (0,0) (6.653,1.39701) 
(6.73628,-2.57781) (2.83963,-6.40383) (-1.3027,-7.62756) 
(-5.2442,-4.20318) (-7.30496,-0.464149) (-46.0595,43.0102) 
(-1.1131,6.52395) (3.2,5.98481) (6.67649,1.87579) 
(6.12278,-2.4737) (3.20924,-5.88361) (-1.73027,-7.05576) 
(-5.08706,-4.94171) (-6.68616,-0.0110321) (-5.45217,3.92032) 
(-1.28323,7.08399) (3.24904,6.21134) (6.67752,2.90531) 
(7.18779,-1.51598) (36.8116,-51.7724) (0.146267,-7.00651) 
(-4.51996,-4.89137) (-7.37838,-1.41322) (-6.20339,3.98806) 
(-2.49422,6.80633) (0,0) (0,0) (0,0) (0,0) (0,0)]


This is weired. The channel is just AWGN.  Why are not the channel 
taps 1?
I found the same question posted before. 
https://lists.gnu.org/archive/html/discuss-gnuradio/2017-05/msg00057.html. 
But didn't see the answer.


I'm running GNU Radio Companion 3.7.12 by the way. The example can be 
found in the attachment.


Regards,
Edwin



___
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] OFDM channel tap questions

[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 wrote:

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,-3.65375) (47.2264,-42.4505) (8.44977,-62.8107) 
(-32.7931,-54.5247) (-59.9085,-21.3488) (-59.8031,23.3288) 
(-32.3382,55.4137) (9.05079,63.8184) (46.331,42.7923) (65.1778,2.83559) 
(51.1081,-38.6363) (15.815,-62.1237) (-27.1419,-57.8722) 
(-58.2753,-27.4043) (-62.3711,15.658) (-37.9986,51.1873) 
(3.2302,64.2116) (5.44772,5.36124) (6.75629,1.41069) (54.079,-33.4137) 
(2.19591,-6.12473) (-1.91544,-6.56722) (-5.87699,-3.166) 
(-6.83039,0.994718) (-4.49682,5.42143) (-0.363706,6.79664) (0,0) 
(6.653,1.39701) (6.73628,-2.57781) (2.83963,-6.40383) (-1.3027,-7.62756) 
(-5.2442,-4.20318) (-7.30496,-0.464149) (-46.0595,43.0102) 
(-1.1131,6.52395) (3.2,5.98481) (6.67649,1.87579) (6.12278,-2.4737) 
(3.20924,-5.88361) (-1.73027,-7.05576) (-5.08706,-4.94171) 
(-6.68616,-0.0110321) (-5.45217,3.92032) (-1.28323,7.08399) 
(3.24904,6.21134) (6.67752,2.90531) (7.18779,-1.51598) 
(36.8116,-51.7724) (0.146267,-7.00651) (-4.51996,-4.89137) 
(-7.37838,-1.41322) (-6.20339,3.98806) (-2.49422,6.80633) (0,0) (0,0) 
(0,0) (0,0) (0,0)]


This is weired. The channel is just AWGN.  Why are not the channel taps 1?
I found the same question posted before. 
https://lists.gnu.org/archive/html/discuss-gnuradio/2017-05/msg00057.html. 
But didn't see the answer.


I'm running GNU Radio Companion 3.7.12 by the way. The example can be 
found in the attachment.


Regards,
Edwin



___
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] OFDM channel tap questions

[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,-3.65375) (47.2264,-42.4505) (8.44977,-62.8107)
(-32.7931,-54.5247) (-59.9085,-21.3488) (-59.8031,23.3288)
(-32.3382,55.4137) (9.05079,63.8184) (46.331,42.7923) (65.1778,2.83559)
(51.1081,-38.6363) (15.815,-62.1237) (-27.1419,-57.8722)
(-58.2753,-27.4043) (-62.3711,15.658) (-37.9986,51.1873) (3.2302,64.2116)
(5.44772,5.36124) (6.75629,1.41069) (54.079,-33.4137) (2.19591,-6.12473)
(-1.91544,-6.56722) (-5.87699,-3.166) (-6.83039,0.994718)
(-4.49682,5.42143) (-0.363706,6.79664) (0,0) (6.653,1.39701)
(6.73628,-2.57781) (2.83963,-6.40383) (-1.3027,-7.62756) (-5.2442,-4.20318)
(-7.30496,-0.464149) (-46.0595,43.0102) (-1.1131,6.52395) (3.2,5.98481)
(6.67649,1.87579) (6.12278,-2.4737) (3.20924,-5.88361) (-1.73027,-7.05576)
(-5.08706,-4.94171) (-6.68616,-0.0110321) (-5.45217,3.92032)
(-1.28323,7.08399) (3.24904,6.21134) (6.67752,2.90531) (7.18779,-1.51598)
(36.8116,-51.7724) (0.146267,-7.00651) (-4.51996,-4.89137)
(-7.37838,-1.41322) (-6.20339,3.98806) (-2.49422,6.80633) (0,0) (0,0) (0,0)
(0,0) (0,0)]

This is weired. The channel is just AWGN.  Why are not the channel taps 1?
I found the same question posted before.
https://lists.gnu.org/archive/html/discuss-gnuradio/2017-05/msg00057.html.
But didn't see the answer.

I'm running GNU Radio Companion 3.7.12 by the way. The example can be found
in the attachment.

Regards,
Edwin


rx_ofdm.grc
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[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 filters is 3.44 dB at 15000 Hz.
> 
> It bends up because your plot has got one log axis and one linear
> one.

Ah yes, of course.

And on that note, the bilinear transform design method warps the
GNURadio FM de-emphasis filter line downward on the log-log graph,
which is expected.

Regards,
Andy

> If plotted with a log frequency axis rather than a linear one then
> the
> slope at the right should tend to a straight line of 6.02 dB/octave
> or
> 20 dB/decade. Indeed the idea of dB/octave or dB/decade only makes
> sense
> if you use a log frequency axis.
> 
> Alternatively, you could use a linear voltage axis instead of dB, and
> a
> linear frequency axis. That should also tend towards a straight line
> on
> the right hand side.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[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 0.000.00
>> 300   -0.09   -0.04
>> 500   -0.23   -0.11
>> 1000  -0.87   -0.41
>> 3000  -4.77   -2.76
>> 5000  -8.16   -5.40
>> 8000 -11.82   -8.64
>> 1-13.65  -10.36
>> 12500-15.52  -12.15
>> 15000-17.07  -13.65
>>
> 
> FWIW, the attached plots compare the 50 us de-emphasis filter response
> of GNURadio 3.7.10 vs. the numbers you provided.

FWIW they are not my numbers, but appeared to come from a reliable source.

> 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 filters is 3.44 dB at 15000 Hz.

It bends up because your plot has got one log axis and one linear one.

If plotted with a log frequency axis rather than a linear one then the
slope at the right should tend to a straight line of 6.02 dB/octave or
20 dB/decade. Indeed the idea of dB/octave or dB/decade only makes sense
if you use a log frequency axis.

Alternatively, you could use a linear voltage axis instead of dB, and a
linear frequency axis. That should also tend towards a straight line on
the right hand side.

-- 
Richard Lamont

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

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

[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 in items), 
then they are just added as meta-data to the PDU. Each PDU is created 
independent of the other PDUs, and just 1 created per call to "work". Not sure 
if this is what you were looking to have answered; if not, please clarity. 
Cheers! - MLD

On Wed, Jan 10, 2018, at 11:30 AM, Dave NotTelling wrote:
> 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 for a second that several of the offsets in the tagged stream are 
> very small (only say 10 samples each) and back to back
>  * Is there a guarantee that each of the 10 sample offsets will result in a 
> single PDU?
>
>Looking at the source of tagged_stream_to_pdu it seems that there is no check 
>that multiple tag offsets arrived in a single call to work.  Or is that 
>something that cannot happen?  Having a contract that no more than one offset 
>can arrive at a single call to work would be really nice, but I imagine that 
>doing so could cause some pretty serious performance issues.

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

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

[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 the usual. Hope 
this helps! - MLD

On Wed, Jan 10, 2018, at 2:08 PM, Mercado, Alejandra via USRP-users wrote:
> When I followed instructions to make both the UHD and the GNURadio, I got a 
> slew of warnings. Later I ran the GnuRadio test and got one error:
> 99% tests passed, 1 tests failed out of 212
> 
> Total Test time (real) = 140.04 sec
> 
> The following tests FAILED:
> 209 - qa_zeromq_pub (Failed)
> Errors while running CTest
> Makefile:149: recipe for target 'test' failed
> make: *** [test] Error 8
> 
> Any suggestions?

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

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

[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 'top' in the the audio. I have been using the FM
> de-emphasis block that is shipped in the Ubuntu gnuradio 3.7.9
> package -
> I have added any others yet.

[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 0.000.00
> 300   -0.09   -0.04
> 500   -0.23   -0.11
> 1000  -0.87   -0.41
> 3000  -4.77   -2.76
> 5000  -8.16   -5.40
> 8000 -11.82   -8.64
> 1-13.65  -10.36
> 12500-15.52  -12.15
> 15000-17.07  -13.65
> 

FWIW, the attached plots compare the 50 us de-emphasis filter response
of GNURadio 3.7.10 vs. the numbers you provided.

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 filters is 3.44 dB at 15000 Hz.

So hopefully you won't hear to much 'top' in your audio using 3.7.10's
filter.

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

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

[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 for a second that several of the offsets in the tagged stream
   are very small (only say 10 samples each) and back to back
   - Is there a guarantee that each of the 10 sample offsets will result in
   a single PDU?

Looking at the source of tagged_stream_to_pdu it seems that there is no
check that multiple tag offsets arrived in a single call to work.  Or is
that something that cannot happen?  Having a contract that no more than one
offset can arrive at a single call to work would be really nice, but I
imagine that doing so could cause some pretty serious performance issues O.o
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[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.
--   Override with -DENABLE_GR_FEC=ON/OFF
-- checking for module 'fftw3f >= 3.0'
--   package 'fftw3f >= 3.0' not found
-- Could NOT find FFTW3F (missing:  FFTW3F_LIBRARIES FFTW3F_INCLUDE_DIRS)
-- 
-- Configuring gr-fft support...
--   Dependency ENABLE_VOLK = ON
--   Dependency Boost_FOUND = 1
--   Dependency ENABLE_GNURADIO_RUNTIME = ON
--   Dependency ENABLE_GR_BLOCKS = ON
--   Dependency FFTW3F_FOUND = FALSE
--   Disabling gr-fft support.
--   Override with -DENABLE_GR_FFT=ON/OFF

Notice that fftwf3 is missing which means you don't have libfftw which
means no FFT support.  Since you're running Ubuntu you should look at
https://wiki.gnuradio.org/index.php/UbuntuInstall and run the canned
apt-get commands for your version.

On Tue, Jan 9, 2018 at 11:48 PM, Koyel Das  wrote:

> Hi,
>
> yes cmake of gnuradio has gr-fft and many other components disables.
> Following is the outcome of cmake
>
> -- Build type not specified: defaulting to release.
> -- Build type set to Release.
> -- Extracting version information from git describe...
> -- Compiler Version: cc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4
> Copyright (C) 2013 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> -- Compiler Flags: /usr/bin/cc:::-O3 -DNDEBUG  -std=gnu99
> -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized
> /usr/bin/c++:::-O3 -DNDEBUG  -std=c++98 -fvisibility=hidden -Wsign-compare
> -Wall -Wno-uninitialized
> -- ADDING PERF COUNTERS
> -- Building Static Libraries: OFF
> -- Boost version: 1.54.0
> -- Found the following Boost libraries:
> --   date_time
> --   program_options
> --   filesystem
> --   system
> --   regex
> --   thread
> -- Enabling use of known bad versions of Boost.
> -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found
> suitable version "2.7.6", minimum required is "2.7")
> --
> -- Checking for module SWIG
> -- Found SWIG version 2.0.11.
> -- Requested SWIG version is at least .
> -- Disabling SWIG because version check failed.
> --
> -- The build system will automatically enable all components.
> -- Use -DENABLE_DEFAULT=OFF to disable components by default.
> --
> -- Configuring python-support support...
> --   Dependency PYTHONLIBS_FOUND = TRUE
> --   Dependency SWIG_FOUND = FALSE
> --   Dependency SWIG_VERSION_CHECK = FALSE
> --   Disabling python-support support.
> --   Override with -DENABLE_PYTHON=ON/OFF
> --
> -- Configuring testing-support support...
> --   Dependency CPPUNIT_FOUND = TRUE
> --   Enabling testing-support support.
> --   Override with -DENABLE_TESTING=ON/OFF
> --
> -- Configuring VOLK support...
> -- Build type set to Release.
> -- Extracting version information from git describe...
> --
> -- Python checking for python >= 2.5
> -- Python checking for python >= 2.5 - found
> --
> -- Python checking for Cheetah >= 2.0.0
> -- Python checking for Cheetah >= 2.0.0 - found
> -- Boost version: 1.54.0
> -- Found the following Boost libraries:
> --   filesystem
> --   system
> --   unit_test_framework
> --   program_options
> -- Enabling use of known bad versions of Boost.
> -- checking for module 'orc-0.4 > 0.4.11'
> --   package 'orc-0.4 > 0.4.11' not found
> -- orc files (missing:  ORC_LIBRARY ORC_INCLUDE_DIR ORCC_EXECUTABLE)
> -- QA Testing is enabled.
> --   Modify using: -DENABLE_TESTING=ON/OFF
> -- System profiling is disabled.
> --   Modify using: -DENABLE_PROFILING=ON/OFF
> -- Compiler name: GNU
> -- x86* CPU detected
> -- ORC support not found, Overruled arch orc
> -- CPU width is 64 bits, Overruled arch 32
> -- Available architectures: generic;64;3dnow;abm;popcount;
> mmx;fma;sse;sse2;norc;sse3;ssse3;sse4_a;sse4_1;sse4_2;avx;avx2
> -- Available machines: generic;sse2_64_mmx;sse3_64_
> mmx;ssse3_64_mmx;sse4_a_64_mmx;sse4_1_64_mmx;sse4_2_64_
> mmx;avx_64_mmx;avx2_64_mmx
> -- BUILD TYPE = RELEASE
> -- Base cflags = -O3 -DNDEBUG  -std=gnu99 -fvisibility=hidden
> -Wsign-compare -Wall -Wno-uninitialized -Wall
> -- BUILD INFO ::: generic ::: GNU ::: -O3 -DNDEBUG  -std=gnu99
> -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -Wall
> -- BUILD INFO ::: sse2_64_mmx ::: GNU ::: -O3 -DNDEBUG  -std=gnu99
> -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -Wall -m64
> -mmmx -msse -msse2
> -- BUILD INFO ::: sse3_64_mmx ::: GNU ::: -O3 -DNDEBUG  -std=gnu99
> -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -Wall -m64
> -mmmx -msse -msse2 -msse3
> -- BUILD INFO ::: ssse3_64_mmx ::: GNU ::: -O3 -DNDEBUG  -std=gnu99
> -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -Wall -m64
> -mmmx -msse -msse2 -msse3 

[Discuss-gnuradio] Poly Filter Bank for unfiltered signals

[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 (to represent a filter with impulse response of a
rectangular waveform) but this throws a runtime error saying differential
filter taps produces NaN.

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