Re: [Discuss-gnuradio] Question about tagged_stream_block

[bob wole]

Martin thanks for you reply.


I was looking at things wrongly. Now, I ask the scheduler for atleast 1000
samples at a time, using set_output_multiple() and I adjust the tag value
if overflow occurs.Thanks again for correction.

--
Bob


> If you change the size of a tagged stream without changing the tag,
> you're producing invalid data. (This may change on 3.8, we haven't
> finalized any decisions yet).
>
> However, how are you dropping samples in software? Or are you dropping
> them in hardware, in which case why are you not tagging the streams
> correctly?
>
> M
>
> On 06/22/2016 12:10 AM, bob wole wrote:
> > Thanks Martin,
> >
> > I know the packet size a priori but samples may drop due to overflows
> > while flowgraph is running and could result in different packet size. Is
> > there a way to solve this issue while using tagged_stream_block?
> >
> > --
> > Bob
> >
> >
> > It'll crash. If you know your packet size a priori, you can tell the
> > scheduler to only provide multiples of a 1000 samples.
> >
> > Cheers,
> > M
> >
> > On 06/20/2016 07:17 AM, bob wole wrote:
> > > Hi,
> > > My  flowgraph contains a tagged_stream_block, B, and it has a
> > > length_tag_key, say "pkt_len". Each packet has a length of 1000
> > samples.
> > > The upstream block (A-->B) tags first sample with key "pkt_len" and
> > > value 1000 and then the upstream block tags sample number 901 with
> key
> > > "pkt_len" and value 1000 instead of tagging sample number 1001.
> This
> > > could happen in case of overflow and I know using receive tags
> > that 100
> > > samples has been lost. So, samples from 901 to 1900 contains a new
> > > packet. Will the flowgraph work or will it crash?
> > >
> > > I want to write a block that processes exactly only 1000 samples,
> one
> > > packet, in a call to work. And the packets start from a specific
> time
> > > for example when the rx_time of the sample is mid of any second.
> > >
> > >
> > > --
> > > Bob
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Question about tagged_stream_block

[bob wole]

Thanks Martin,

I know the packet size a priori but samples may drop due to overflows while
flowgraph is running and could result in different packet size. Is there a
way to solve this issue while using tagged_stream_block?

--
Bob


> It'll crash. If you know your packet size a priori, you can tell the
> scheduler to only provide multiples of a 1000 samples.
>
> Cheers,
> M
>
> On 06/20/2016 07:17 AM, bob wole wrote:
> > Hi,
> > My  flowgraph contains a tagged_stream_block, B, and it has a
> > length_tag_key, say "pkt_len". Each packet has a length of 1000 samples.
> > The upstream block (A-->B) tags first sample with key "pkt_len" and
> > value 1000 and then the upstream block tags sample number 901 with key
> > "pkt_len" and value 1000 instead of tagging sample number 1001. This
> > could happen in case of overflow and I know using receive tags that 100
> > samples has been lost. So, samples from 901 to 1900 contains a new
> > packet. Will the flowgraph work or will it crash?
> >
> > I want to write a block that processes exactly only 1000 samples, one
> > packet, in a call to work. And the packets start from a specific time
> > for example when the rx_time of the sample is mid of any second.
> >
> >
> > --
> > Bob
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Question about tagged_stream_block

[bob wole]

Hi,
My  flowgraph contains a tagged_stream_block, B, and it has a
length_tag_key, say "pkt_len". Each packet has a length of 1000 samples.
The upstream block (A-->B) tags first sample with key "pkt_len" and value
1000 and then the upstream block tags sample number 901 with key "pkt_len"
and value 1000 instead of tagging sample number 1001. This could happen in
case of overflow and I know using receive tags that 100 samples has been
lost. So, samples from 901 to 1900 contains a new packet. Will the
flowgraph work or will it crash?

I want to write a block that processes exactly only 1000 samples, one
packet, in a call to work. And the packets start from a specific time for
example when the rx_time of the sample is mid of any second.


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

Re: [Discuss-gnuradio] [USRP-users] Switching and high spike in spectrum

[bob wole]

Hi,

Sorry for late reply. I was running out of time, so I used the offset tune
future of UHD to handle that spike. See the following link, hope it helps,

http://files.ettus.com/manual/structuhd_1_1tune__request__t.html

--
Bob

On Sat, Apr 2, 2016 at 7:41 AM, hanwen  wrote:

> Hi Bob,
>
> I came up with the same issue and I hope the DC leakage from Tx should
> disappear right after the Tx burst is finished, but acturally I still saw
> the strong DC during the pure Rx time lot.
> Have you got a solution for that? Thanks.
>
> Br, Hanwen
>
> 2014-10-31 7:31 GMT+01:00 bob wole :
>
>>
>>
>>
>> On 10/29/2014 01:54 PM, bob wole via USRP-users wrote:
>>> >
>>> > USRPN210r4 with SBX
>>> >
>>> > I am observing a strong spike at the center of the receive spectrum
>>> > when I start burst transmission.
>>> >
>>> > My top flowgraph contains following two hierarchical blocks
>>> >  1) A transmitter flow graph with (tx_time, tx_sob, tx_eob)
>>> >  2) A receiver flow graph
>>> >
>>> > When I run top flowgrpah (without transmitting anything) and observe
>>> > the FFT of the received signal the spectrum does not contain high
>>> > spike in the center.
>>> >
>>> > But as soon as I start transmitting in burst mode I see a very high
>>> > spike in center of the received signal FFT spectrum. It looks like LO
>>> > (transmitter or receiver ) is being received? Which one is it ? And
>>> > why is it happening?  How can I avoid it because it is affecting my
>>> > packets.
>>> >
>>> > When I apply the offset in digital using DDC/DUC, the spike moves out
>>> > of the band.
>>> >
>>> >
>>> > --
>>> > Bob
>>> >
>>> >
>>> > ___
>>> > USRP-users mailing list
>>> > usrp-us...@lists.ettus.com
>>> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>> That spike in the middle is a consequence of using direct conversion in
>>> both the RX and TX paths--it'll be there in both to some degree.
>>>
>>> You can use offset-tuning to move the DC offset outside your passband:
>>>
>>> http://files.ettus.com/manual/page_general.html
>>>
>>>
>>> In built-for-a-particular-purpose radios, there will also be undesired
>>> LO leakage and mixing products--those are generally dealt with using an
>>>application/band-specific filter to eliminate them.  For
>>> general-purpose SDRs, that isn't possible to do "as manufactured", you
>>> have to deal
>>>with RF hygiene and plumbing issues yourself.
>>>
>>> So, moving the LO leakage outside your passband is part of the
>>> picture--use offset tuning for that.  Then, if you have "this won't meet
>>>our hygiene requirements", you have to look at filtering.
>>>
>>> Another thing you really should do is to run the calibration utilities,
>>> which will attempt to balance I/Q amplitude and phase, which can improve
>>>some of these issues, but not, usually, eliminate them entirely.
>>>
>>>
>>>
>> Yes, I know that LO leakage/DC offset is an issue present in direct
>> conversion receiver. But as I mentioned earlier, the received spectrum
>> looks fine (a very little spike at DC around -70dB) while the burst
>> transmission is not running. The spike becomes much more significant ( high
>> spike at DC -20dB) when burst transmission (tx_time,tx_eob, tx_sob )
>> starts  and all the spectrum just shifts up and down with it. I am using
>> TX/RX antenna in both usrp source and usrp sink. I want to know why the
>> burst transmission is affecting the received spectrum on the same node.
>>
>>
>> ___
>> 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] gmsk+fec

[bob wole]

Ekko,

Add a Tag debug block after your packet encoder and see if there are any
tags coming out of it. I think packet encoder is not passing your tag. If
that is the case, move your stream to tagged stream block after the packet
encoder just before the FEC extended tagged encoder. Hope it helps.


--
Bob


>
> this is the address of picture
>
> http://imgur.com/2EQiY6O
>
> sorry to send two e-mails
>
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Mailing list archive looks broken

[bob wole]

>
>
> The ML archive here looks like it has stopped updating:
>
> http://lists.gnu.org/archive/html/discuss-gnuradio/2015-10/index.html
>
> Regards,
> Andy
>
>
>
I am also unable to see recent threads. Only one email for this month.

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

Re: [Discuss-gnuradio] Discuss-gnuradio Digest, Vol 155, Issue 4

[bob wole]

>
> The ML archive here looks like it has stopped updating:
>
> http://lists.gnu.org/archive/html/discuss-gnuradio/2015-10/index.html
>
> Regards,
> Andy
>
>
>
I am also unable to see recent threads. Only one email for this month.

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

Re: [Discuss-gnuradio] Question about correlate_access_code_bb_impl

[bob wole]

On Mon, Sep 21, 2015 at 7:38 PM, Tom Rondeau  wrote:

> On Mon, Sep 21, 2015 at 6:40 AM, bob wole  wrote:
>
>> I am studying the code of correlate_access_code_bb_impl.cc for
>> understanding its working. I see that the block is derive from "block"
>> class of gr as written in correlate_access_code_bb_ts.h file
>>
>>
>> class DIGITAL_API correlate_access_code_bb_ts : virtual public block
>>
>>
>> I read earlier that blocks derived from "block"/"gr::block"  should
>> implement forecast() method, but I did not see any implementation of
>> forecast() in  code of correlate_access_code_bb_impl.cc.
>>
>> Can somebody please tell me why ?
>>
>> --
>> Bob
>>
>
>
> First, you have a misunderstanding of the header/source relationship.
> There are a number of correlate* blocks in GNU Radio (and an unwritten plan
> to organize them better in the future). The correlate_access_code_bb is one
> block, and this is a gr::sync_block. The correlate_access_code_bb_ts is
> another block, and this one is a gr::block.
>
> If you look at the code for block.cc, you'll see it implements a forecast
> function already:
>
>   void
>   block::forecast(int noutput_items, gr_vector_int &ninput_items_required)
>   {
> unsigned ninputs = ninput_items_required.size ();
> for(unsigned i = 0; i < ninputs; i++)
>   ninput_items_required[i] = noutput_items + history() - 1;
>   }
>
>
> That means that any block that derives from gr::block gets this behavior,
> which tells the scheduler that given noutput_items, the block needs this
> many input items to produce that output amount. This is a satisfactory
> condition for many blocks, so no, you don't /have/ to overload forecast in
> your derived block if this condition meets your block's behavior.
>
> Tom
>
>
Hi Tom,

Sorry, actually there were typos in my email. I was talking about the block
"correlate_access_code_bb_ts" all the time instead of
"correlate_access_code_bb". Thanks for clearing things and being helpful as
always.


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

[Discuss-gnuradio] Question about correlate_access_code_bb_impl

[bob wole]

I am studying the code of correlate_access_code_bb_impl.cc for
understanding its working. I see that the block is derive from "block"
class of gr as written in correlate_access_code_bb_ts.h file


class DIGITAL_API correlate_access_code_bb_ts : virtual public block


I read earlier that blocks derived from "block"/"gr::block"  should
implement forecast() method, but I did not see any implementation of
forecast() in  code of correlate_access_code_bb_impl.cc.

Can somebody please tell me why ?

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

Re: [Discuss-gnuradio] Convolutional Code output does not match polynomial

[bob wole]

I have opened an issue on the gnuradio.org. See the link below

http://gnuradio.org/redmine/issues/841


--
Bob

On Sat, Sep 12, 2015 at 1:36 PM, bob wole  wrote:

> Okay. I registered my self at gnuradio.org. Do I have to open a new Issue
> on the website?
>
> --
> Bob
>
>
>
>> Jan, Bob,
>>
>> might be worth opening a ticket for this.
>>
>> M
>> On 10.09.2015 00:22, bob wole wrote:
>> > Hey Jan,
>> >
>> > Thanks for your reply, you are correct about the bit shift being LSB.
>> > So, I reversed the bit order of polynomials 1101101 to 1011011 and
>> > 100 to 001 in MATLAB, Now the output of gnuradio and MATLAB and
>> > my dry run matches. I am wondering why they did implementation like
>> > this? Any advantages?
>> >
>> > Yeah, I too was hoping for a reply from Tom and Nick on this.
>> >
>> >
>> > --
>> > Bob
>> >
>> >
>> > On Tue, Sep 8, 2015 at 12:37 PM, Jan Kr?mer > > <mailto:kraemer...@gmail.com>> wrote:
>> >
>> > Also I think Tom and Nick Foster for sure know more about it than I
>> do.
>> >
>> > Cheers,
>> > Jan
>> >
>> > 2015-09-08 8:44 GMT+02:00 Jan Kr?mer > > <mailto:kraemer...@gmail.com>>:
>> >
>> > Hey Bob,
>> >
>> > I have the same issues with my SSE Viterbi, works with
>> > gr-trellis but not with cc_encoder in gr-fec. The output of the
>> > cc_encoder is legit though.
>> > I talked to a couple of guys about this at last year's GRCON. It
>> > seems that in most implementations, the bit order of the
>> > polynomials is reversed when compared to the textbook approach.
>> > Therefor also the bit shifting in the encoding process (and the
>> > viterbi chainback) is also reversed. I think textbook is MSB
>> > while cc_encoder is LSB but I always mix them up xD.
>> > But you can check
>> >
>> https://github.com/gnuradio/gnuradio/blob/master/gr-fec/lib/cc_encoder_impl.cc
>> > beginning from line 166.
>> >
>> > Hope that helps,
>> > Jan
>> >
>> > 2015-09-08 8:12 GMT+02:00 bob wole > > <mailto:bnw...@gmail.com>>:
>> >
>> >
>> >
>> > On Tue, Sep 1, 2015 at 2:55 PM, bob wole > > <mailto:bnw...@gmail.com>> wrote:
>> >
>> > I am trying channel coding in gnuradio. I am using
>> > convolutional encoder with K=7 and R=1/2 with
>> > polynomials [109, 79] (default). However I am not
>> > getting the expected result. I input a known bit
>> > sequence, single frame using head block, and observe the
>> > output of the encoder using file sink. The output I
>> > think is not correct according to the given polynomials.
>> > Input bit stream is
>> >
>> > http://pastebin.com/thsYtLFG
>> >
>> > I am getting this output
>> >
>> > http://pastebin.com/P42QNjiE
>> >
>> > However, I am expecting (in hex)
>> >
>> > 0000E33263D74BFAD3
>> ..
>> >
>> >
>> >  I have attached the flowgraph I am using for this
>> > purpose. I did a dry run by drawing a diagram of the
>> > encoder and inputing  initial two bytes. Diagram of the
>> > encoder is also attached. I also used MATLAB script to
>> > test and found that my dry run output matches with
>> > MATLAB but not with Gnuradio output. I also played with
>> > the endianness but could not get the desired result.
>> > Maybe I am doing something wrong in configuring the
>> encoder?
>> >
>> >
>> > Also another thing I noticed is that in QA codes of
>> > gr-fec I found
>> >
>> > import fec_swig as fec
>> > import blocks_swig as blocks
>> >
>> > I think this should be
>> >
>> > from gnuradio import fec, blocks
>> >
>> > Am I right? I am using gnuradio 3.7.8.
>> >
>> > --
>> > Bob
>> >
>> >
>> >
>> > I am still waiting to get a reply on this. Anyone else
>> > verified the output of the convolutional encoder?
>> >
>> >
>> > --
>> > Bob
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Convolutional Code output does not match polynomial

[bob wole]

Okay. I registered my self at gnuradio.org. Do I have to open a new Issue
on the website?

--
Bob



> Jan, Bob,
>
> might be worth opening a ticket for this.
>
> M
> On 10.09.2015 00:22, bob wole wrote:
> > Hey Jan,
> >
> > Thanks for your reply, you are correct about the bit shift being LSB.
> > So, I reversed the bit order of polynomials 1101101 to 1011011 and
> > 100 to 001 in MATLAB, Now the output of gnuradio and MATLAB and
> > my dry run matches. I am wondering why they did implementation like
> > this? Any advantages?
> >
> > Yeah, I too was hoping for a reply from Tom and Nick on this.
> >
> >
> > --
> > Bob
> >
> >
> > On Tue, Sep 8, 2015 at 12:37 PM, Jan Kr?mer  > <mailto:kraemer...@gmail.com>> wrote:
> >
> > Also I think Tom and Nick Foster for sure know more about it than I
> do.
> >
> > Cheers,
> > Jan
> >
> > 2015-09-08 8:44 GMT+02:00 Jan Kr?mer  > <mailto:kraemer...@gmail.com>>:
> >
> > Hey Bob,
> >
> > I have the same issues with my SSE Viterbi, works with
> > gr-trellis but not with cc_encoder in gr-fec. The output of the
> > cc_encoder is legit though.
> > I talked to a couple of guys about this at last year's GRCON. It
> > seems that in most implementations, the bit order of the
> > polynomials is reversed when compared to the textbook approach.
> > Therefor also the bit shifting in the encoding process (and the
> > viterbi chainback) is also reversed. I think textbook is MSB
> > while cc_encoder is LSB but I always mix them up xD.
> > But you can check
> >
> https://github.com/gnuradio/gnuradio/blob/master/gr-fec/lib/cc_encoder_impl.cc
> > beginning from line 166.
> >
> > Hope that helps,
> > Jan
> >
> > 2015-09-08 8:12 GMT+02:00 bob wole  > <mailto:bnw...@gmail.com>>:
> >
> >
> >
> > On Tue, Sep 1, 2015 at 2:55 PM, bob wole  > <mailto:bnw...@gmail.com>> wrote:
> >
> > I am trying channel coding in gnuradio. I am using
> > convolutional encoder with K=7 and R=1/2 with
> > polynomials [109, 79] (default). However I am not
> > getting the expected result. I input a known bit
> > sequence, single frame using head block, and observe the
> > output of the encoder using file sink. The output I
> > think is not correct according to the given polynomials.
> > Input bit stream is
> >
> > http://pastebin.com/thsYtLFG
> >
> > I am getting this output
> >
> > http://pastebin.com/P42QNjiE
> >
> > However, I am expecting (in hex)
> >
> > 0000E33263D74BFAD3 ..
> >
> >
> >  I have attached the flowgraph I am using for this
> > purpose. I did a dry run by drawing a diagram of the
> > encoder and inputing  initial two bytes. Diagram of the
> > encoder is also attached. I also used MATLAB script to
> > test and found that my dry run output matches with
> > MATLAB but not with Gnuradio output. I also played with
> > the endianness but could not get the desired result.
> > Maybe I am doing something wrong in configuring the
> encoder?
> >
> >
> > Also another thing I noticed is that in QA codes of
> > gr-fec I found
> >
> > import fec_swig as fec
> > import blocks_swig as blocks
> >
> > I think this should be
> >
> > from gnuradio import fec, blocks
> >
> > Am I right? I am using gnuradio 3.7.8.
> >
> > --
> > Bob
> >
> >
> >
> > I am still waiting to get a reply on this. Anyone else
> > verified the output of the convolutional encoder?
> >
> >
> > --
> > Bob
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Convolutional Code output does not match polynomial

[bob wole]

Hey Jan,

Thanks for your reply, you are correct about the bit shift being LSB. So, I
reversed the bit order of polynomials 1101101 to 1011011 and 100 to
001 in MATLAB, Now the output of gnuradio and MATLAB and my dry run
matches. I am wondering why they did implementation like this? Any
advantages?

Yeah, I too was hoping for a reply from Tom and Nick on this.


--
Bob


On Tue, Sep 8, 2015 at 12:37 PM, Jan Krämer  wrote:

> Also I think Tom and Nick Foster for sure know more about it than I do.
>
> Cheers,
> Jan
>
> 2015-09-08 8:44 GMT+02:00 Jan Krämer :
>
>> Hey Bob,
>>
>> I have the same issues with my SSE Viterbi, works with gr-trellis but not
>> with cc_encoder in gr-fec. The output of the cc_encoder is legit though.
>> I talked to a couple of guys about this at last year's GRCON. It seems
>> that in most implementations, the bit order of the polynomials is reversed
>> when compared to the textbook approach.
>> Therefor also the bit shifting in the encoding process (and the viterbi
>> chainback) is also reversed. I think textbook is MSB while cc_encoder is
>> LSB but I always mix them up xD.
>> But you can check
>> https://github.com/gnuradio/gnuradio/blob/master/gr-fec/lib/cc_encoder_impl.cc
>> beginning from line 166.
>>
>> Hope that helps,
>> Jan
>>
>> 2015-09-08 8:12 GMT+02:00 bob wole :
>>
>>>
>>>
>>> On Tue, Sep 1, 2015 at 2:55 PM, bob wole  wrote:
>>>
>>>> I am trying channel coding in gnuradio. I am using convolutional
>>>> encoder with K=7 and R=1/2 with polynomials [109, 79] (default). However I
>>>> am not getting the expected result. I input a known bit sequence, single
>>>> frame using head block, and observe the output of the encoder using file
>>>> sink. The output I think is not correct according to the given polynomials.
>>>> Input bit stream is
>>>>
>>>> http://pastebin.com/thsYtLFG
>>>>
>>>> I am getting this output
>>>>
>>>> http://pastebin.com/P42QNjiE
>>>>
>>>> However, I am expecting (in hex)
>>>>
>>>> 0000E33263D74BFAD3 ..
>>>>
>>>>
>>>>  I have attached the flowgraph I am using for this purpose. I did a dry
>>>> run by drawing a diagram of the encoder and inputing  initial two bytes.
>>>> Diagram of the encoder is also attached. I also used MATLAB script to test
>>>> and found that my dry run output matches with MATLAB but not with Gnuradio
>>>> output. I also played with the endianness but could not get the desired
>>>> result. Maybe I am doing something wrong in configuring the encoder?
>>>>
>>>>
>>>> Also another thing I noticed is that in QA codes of gr-fec I found
>>>>
>>>> import fec_swig as fec
>>>> import blocks_swig as blocks
>>>>
>>>> I think this should be
>>>>
>>>> from gnuradio import fec, blocks
>>>>
>>>> Am I right? I am using gnuradio 3.7.8.
>>>>
>>>> --
>>>> Bob
>>>>
>>>
>>>
>>> I am still waiting to get a reply on this. Anyone else verified the
>>> output of the convolutional encoder?
>>>
>>>
>>> --
>>> Bob
>>>
>>> ___
>>> 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] Convolutional Code output does not match polynomial

[bob wole]

On Tue, Sep 1, 2015 at 2:55 PM, bob wole  wrote:

> I am trying channel coding in gnuradio. I am using convolutional encoder
> with K=7 and R=1/2 with polynomials [109, 79] (default). However I am not
> getting the expected result. I input a known bit sequence, single frame
> using head block, and observe the output of the encoder using file sink.
> The output I think is not correct according to the given polynomials. Input
> bit stream is
>
> http://pastebin.com/thsYtLFG
>
> I am getting this output
>
> http://pastebin.com/P42QNjiE
>
> However, I am expecting (in hex)
>
> 0000E33263D74BFAD3 ..
>
>
>  I have attached the flowgraph I am using for this purpose. I did a dry
> run by drawing a diagram of the encoder and inputing  initial two bytes.
> Diagram of the encoder is also attached. I also used MATLAB script to test
> and found that my dry run output matches with MATLAB but not with Gnuradio
> output. I also played with the endianness but could not get the desired
> result. Maybe I am doing something wrong in configuring the encoder?
>
>
> Also another thing I noticed is that in QA codes of gr-fec I found
>
> import fec_swig as fec
> import blocks_swig as blocks
>
> I think this should be
>
> from gnuradio import fec, blocks
>
> Am I right? I am using gnuradio 3.7.8.
>
> --
> Bob
>


I am still waiting to get a reply on this. Anyone else verified the output
of the convolutional encoder?


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

Re: [Discuss-gnuradio] Better approach for FEC

[bob wole]

>
>
> > I think many of the folks who would have comments on this are at the Gnu
> > Radio conference this week
> >
> >
> >
> > On 08/26/2015 02:09 PM, bob wole wrote:
> >
> >
> >
> > On Tue, Aug 25, 2015 at 11:36 PM, bob wole  wrote:
> >
> >> Hi,
> >>
> >> I have a burst system in gnuradio which is working fine with usrps. I
> >> have used tags (tx_time, tx_eob and tx_sob) to define packet boundaries
> and
> >> transmission time. Tags are inserted by a block which is connected
> before
> >> the usrp sink. I did not use any "tagged stream block" in the burst
> system.
> >> All the blocks used are streaming blocks.
> >>
> >> Now I want to insert FEC in my system. After going through the FEC API,
> I
> >> realized that I can use any of FEC deployments (Streaming, Tagged
> stream,
> >> Asynchronus). Are there any difference(s) performance wise? Which one
> >> should is better for my system?
> >>
> >> I have attached a picture of my current system and identified where I
> >> want to insert FEC in tx and rx.
> >>
> >> Comments are appreciated.
> >>
> >> --
> >> Bob
> >>
> >
> > Comments please ?
> >
> > --
> > Bob
> >
> >
>
> Bob,
>
> The various models of handling packets through a GNU Radio system are
> dependent on a few things, none of which are easy black/white issues to
> describe or offer support on. Partly, it can just be your opinion on where
> the lines are between the different models; or based on what blocks are
> available in the different models. You don't want to go back and forth,
> though, so when you move from a stream into a PDU-based system, you'll want
> to stay there.
>
> Performance is going to be dependent on the rest of your system as well. We
> can't tell you one is better than the other, but we've put in a lot of
> hooks into the system to help you understand those issues for yourself,
> like using the performance counters and naming each thread with the block
> name so top/htop can help.
>
> Tom
>

Hi Tom,

Thanks for your detailed comment. You are always helpful. I'll learn about
performance counters and will try to use them in the flowgrpahs.


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

[Discuss-gnuradio] Convolutional Code output does not match polynomial

[bob wole]

I am trying channel coding in gnuradio. I am using convolutional encoder
with K=7 and R=1/2 with polynomials [109, 79] (default). However I am not
getting the expected result. I input a known bit sequence, single frame
using head block, and observe the output of the encoder using file sink.
The output I think is not correct according to the given polynomials. Input
bit stream is

http://pastebin.com/thsYtLFG

I am getting this output

http://pastebin.com/P42QNjiE

However, I am expecting (in hex)

0000E33263D74BFAD3 ..


 I have attached the flowgraph I am using for this purpose. I did a dry run
by drawing a diagram of the encoder and inputing  initial two bytes.
Diagram of the encoder is also attached. I also used MATLAB script to test
and found that my dry run output matches with MATLAB but not with Gnuradio
output. I also played with the endianness but could not get the desired
result. Maybe I am doing something wrong in configuring the encoder?


Also another thing I noticed is that in QA codes of gr-fec I found

import fec_swig as fec
import blocks_swig as blocks

I think this should be

from gnuradio import fec, blocks

Am I right? I am using gnuradio 3.7.8.

--
Bob


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

Re: [Discuss-gnuradio] Better approach for FEC

[bob wole]

On Tue, Aug 25, 2015 at 11:36 PM, bob wole  wrote:

> Hi,
>
> I have a burst system in gnuradio which is working fine with usrps. I have
> used tags (tx_time, tx_eob and tx_sob) to define packet boundaries and
> transmission time. Tags are inserted by a block which is connected before
> the usrp sink. I did not use any "tagged stream block" in the burst system.
> All the blocks used are streaming blocks.
>
> Now I want to insert FEC in my system. After going through the FEC API, I
> realized that I can use any of FEC deployments (Streaming, Tagged stream,
> Asynchronus). Are there any difference(s) performance wise? Which one
> should is better for my system?
>
> I have attached a picture of my current system and identified where I want
> to insert FEC in tx and rx.
>
> Comments are appreciated.
>
> --
> Bob
>

Comments please ?

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

[Discuss-gnuradio] Better approach for FEC

[bob wole]

Hi,

I have a burst system in gnuradio which is working fine with usrps. I have
used tags (tx_time, tx_eob and tx_sob) to define packet boundaries and
transmission time. Tags are inserted by a block which is connected before
the usrp sink. I did not use any "tagged stream block" in the burst system.
All the blocks used are streaming blocks.

Now I want to insert FEC in my system. After going through the FEC API, I
realized that I can use any of FEC deployments (Streaming, Tagged stream,
Asynchronus). Are there any difference(s) performance wise? Which one
should is better for my system?

I have attached a picture of my current system and identified where I want
to insert FEC in tx and rx.

Comments are appreciated.

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

Re: [Discuss-gnuradio] hier_blocks2 error

[bob wole]

>
> On 08/13/2015 08:38 AM, bob wole wrote:
> > I am using gnruadio 3.7.8. I have a module (python) which is working
> > well for version 3.6.3. In made necessary changes so that it can work
> > with gnuradio 3.7.8. However I am getting following error
> >
> >   File
> > "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py",
> > line 92, in __getattr__
> > return getattr(self._impl, name)
> > AttributeError: 'hier_block2_sptr' object has no attribute '_hb'
> >
> >
> > I spent a lot of time to figure out this but could not resolve it, so
> > I thought to get help from mailing list.
> >
> > Is this a bug or I am doing something wrong?
>
> What your seeing is the interface wrapper looking for an attribute in
> the wrapped instance 'self._impl' which used to be called 'self._hb'. So
> it tries to lookup that first - and fails. Since both _impl and _hb are
> marked protected they should not be accessed from outside the wrapper
> directly (I remember some WXGUI code did that, but that has been fixed).
> In the gnuradio tree I can't seem to find anything like this.
>
> Can you check and see from where this Exception is raised from?
>
> Sebastian
>

The issue was in my python code that I derived from packet.py file. I was
using this with 3.6.3

gr.io_signature(1, 1,
packet_source._hb.output_signature().sizeof_stream_item(0)) # Output
signature)

I replaced it with

gr.io_signature(1, 1,
packet_source.output_signature().sizeof_stream_item(0)) # Output signature)

GRC flowgraph is working fine.

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

[Discuss-gnuradio] hier_blocks2 error

[bob wole]

I am using gnruadio 3.7.8. I have a module (python) which is working well
for version 3.6.3. In made necessary changes so that it can work with
gnuradio 3.7.8. However I am getting following error

  File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py",
line 92, in __getattr__
return getattr(self._impl, name)
AttributeError: 'hier_block2_sptr' object has no attribute '_hb'


I spent a lot of time to figure out this but could not resolve it, so I
thought to get help from mailing list.

Is this a bug or I am doing something wrong?

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

Re: [Discuss-gnuradio] ControlPort 3.7.8rc1

[bob wole]

On Tue, Aug 11, 2015 at 11:54 AM, Johnathan Corgan  wrote:

> On Tue, Aug 11, 2015 at 4:24 AM, bob wole  wrote:
>
>
>> Anyone successful in applying that patch to thrift 0.9.2 ? Thoughts ?
>>
>
> ​In the mastering of the live SDR image, I had to create a new patch that
> was slightly different from the original one; I suspect the original one
> was based on a different version of thrift than 0.9.2.
>
> In any case, you can try this one, it applies cleanly to the 0.9.2 tag in
> the thrift repository:
>
>
> https://github.com/gnuradio/gnuradio-livesdr/blob/livesdr/custom/gnuradio/thrift-shutdown-fix.diff
> ​
>
> Johnathan Corgan
> Corgan Labs - SDR Training and Development Services
> Intro to SDR Class - Aug. 31-Sep. 1, Columbia, MD
> Intro to SDR Class - Sep. 3-4, Santa Clara, CA
> http://corganlabs.com
>


Thanks for sharing the patch. Applied it and patched successfully.

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

Re: [Discuss-gnuradio] ControlPort 3.7.8rc1

[bob wole]

On Sat, Aug 8, 2015 at 11:20 AM, bob wole  wrote:

>
>
> On Fri, Aug 7, 2015 at 9:51 AM, bob wole  wrote:
>
>>
>>
>> On Thu, Aug 6, 2015 at 6:36 PM, Tom Rondeau  wrote:
>>
>>> On Thu, Aug 6, 2015 at 1:24 AM, bob wole  wrote:
>>>
>>>>
>>>>
>>>> On Wed, Aug 5, 2015 at 6:46 PM, Tom Rondeau  wrote:
>>>>
>>>>> On Wed, Aug 5, 2015 at 1:21 AM, bob wole  wrote:
>>>>>
>>>>>>
>>>>>> > There is a directory
>>>>>>> > gnuradio-runtime/python/gnuradio/ctrlport
>>>>>>> >
>>>>>>> >
>>>>>>> > where you in controlport related stuff.
>>>>>>> >
>>>>>>> > - - Volker
>>>>>>> >
>>>>>>> >
>>>>>>> > Am 04.08.2015 um 10:09 schrieb Jeon:
>>>>>>> >
>>>>>>> > Dear Bob,
>>>>>>> >
>>>>>>> > A few months ago, I've asked a similar question (
>>>>>>> > <
>>>>>>> http://lists.gnu.org/archive/html/discuss-gnuradio/2015-06/msg00197.html
>>>>>>> >
>>>>>>> >
>>>>>>> http://lists.gnu.org/archive/html/discuss-gnuradio/2015-06/msg00197.html
>>>>>>> )
>>>>>>> >
>>>>>>> > and Tom gave me his paper in SIGCOMM.
>>>>>>> >
>>>>>>> > Inspecting GNU Radio Applications with ControlPort and Performance
>>>>>>> Counters
>>>>>>> > Thomas Rondeau, Tim O?Shea, and Nathan Goergen
>>>>>>> >
>>>>>>> > You can get one in
>>>>>>> http://conferences.sigcomm.org/sigcomm/2013/srif.php
>>>>>>> >
>>>>>>> > It does not fully describe how it can be used, though, through
>>>>>>> this you
>>>>>>> > can get a hint.
>>>>>>> >
>>>>>>> > Regards,
>>>>>>> > Jeon.
>>>>>>> >
>>>>>>> > 2015-08-04 16:36 GMT+09:00 bob wole :
>>>>>>> >
>>>>>>> >> Ubuntu 14.04 64-bit
>>>>>>> >>
>>>>>>> >> I just installed frest gnuradio 3.7.8rc1 with control port
>>>>>>> enabled. I
>>>>>>> >> fetched gnuradio using
>>>>>>> >>
>>>>>>> >> git clone --recursive https://github.com/gnuradio/gnuradio.git
>>>>>>> >>
>>>>>>> >>
>>>>>>> >>  Gnuradio enabled component shows
>>>>>>> >>
>>>>>>> >> * gr-ctrlport
>>>>>>> >> * * thrift
>>>>>>> >>
>>>>>>> >> However, I do not see any *gr-ctrlport directory *inside the
>>>>>>> gnuradio
>>>>>>> >> directory. Where is the source code for control port? Also there
>>>>>>> are no
>>>>>>> >> examples for using control port.
>>>>>>> >>
>>>>>>> >> --
>>>>>>> >> Bob
>>>>>>> >>
>>>>>>> >
>>>>>>> You can find more information on these two pages:
>>>>>>>
>>>>>>> http://jenkins.gnuradio.org/manual/doxygen/page_ctrlport.html
>>>>>>>
>>>>>>> http://gnuradio.org/redmine/projects/gnuradio/wiki/ControlPort
>>>>>>>
>>>>>>>
>>>>>>> ControlPort was reintroduced just after the 3.7.7 release so we had
>>>>>>> time to
>>>>>>> test it, but it will be available in the upcoming 3.7.8 release. The
>>>>>>> manual
>>>>>>> page linked above is from our weekly development builds.
>>>>>>>
>>>>>>> This points you to two apps that are installed with ControlPort:
>>>>>>> gr-perf-monitorx and gr-ctrlport-monitor. Other good places to look
>>>>>>> for
>>>>>>> usage is in our QA code. Look in gr-blocks
>>>>>>> for qa_cpp_py_binding.py, qa_cpp_py_binding_set.py,

Re: [Discuss-gnuradio] ControlPort 3.7.8rc1

[bob wole]

On Fri, Aug 7, 2015 at 9:51 AM, bob wole  wrote:

>
>
> On Thu, Aug 6, 2015 at 6:36 PM, Tom Rondeau  wrote:
>
>> On Thu, Aug 6, 2015 at 1:24 AM, bob wole  wrote:
>>
>>>
>>>
>>> On Wed, Aug 5, 2015 at 6:46 PM, Tom Rondeau  wrote:
>>>
>>>> On Wed, Aug 5, 2015 at 1:21 AM, bob wole  wrote:
>>>>
>>>>>
>>>>> > There is a directory
>>>>>> > gnuradio-runtime/python/gnuradio/ctrlport
>>>>>> >
>>>>>> >
>>>>>> > where you in controlport related stuff.
>>>>>> >
>>>>>> > - - Volker
>>>>>> >
>>>>>> >
>>>>>> > Am 04.08.2015 um 10:09 schrieb Jeon:
>>>>>> >
>>>>>> > Dear Bob,
>>>>>> >
>>>>>> > A few months ago, I've asked a similar question (
>>>>>> > <
>>>>>> http://lists.gnu.org/archive/html/discuss-gnuradio/2015-06/msg00197.html
>>>>>> >
>>>>>> >
>>>>>> http://lists.gnu.org/archive/html/discuss-gnuradio/2015-06/msg00197.html
>>>>>> )
>>>>>> >
>>>>>> > and Tom gave me his paper in SIGCOMM.
>>>>>> >
>>>>>> > Inspecting GNU Radio Applications with ControlPort and Performance
>>>>>> Counters
>>>>>> > Thomas Rondeau, Tim O?Shea, and Nathan Goergen
>>>>>> >
>>>>>> > You can get one in
>>>>>> http://conferences.sigcomm.org/sigcomm/2013/srif.php
>>>>>> >
>>>>>> > It does not fully describe how it can be used, though, through this
>>>>>> you
>>>>>> > can get a hint.
>>>>>> >
>>>>>> > Regards,
>>>>>> > Jeon.
>>>>>> >
>>>>>> > 2015-08-04 16:36 GMT+09:00 bob wole :
>>>>>> >
>>>>>> >> Ubuntu 14.04 64-bit
>>>>>> >>
>>>>>> >> I just installed frest gnuradio 3.7.8rc1 with control port
>>>>>> enabled. I
>>>>>> >> fetched gnuradio using
>>>>>> >>
>>>>>> >> git clone --recursive https://github.com/gnuradio/gnuradio.git
>>>>>> >>
>>>>>> >>
>>>>>> >>  Gnuradio enabled component shows
>>>>>> >>
>>>>>> >> * gr-ctrlport
>>>>>> >> * * thrift
>>>>>> >>
>>>>>> >> However, I do not see any *gr-ctrlport directory *inside the
>>>>>> gnuradio
>>>>>> >> directory. Where is the source code for control port? Also there
>>>>>> are no
>>>>>> >> examples for using control port.
>>>>>> >>
>>>>>> >> --
>>>>>> >> Bob
>>>>>> >>
>>>>>> >
>>>>>> You can find more information on these two pages:
>>>>>>
>>>>>> http://jenkins.gnuradio.org/manual/doxygen/page_ctrlport.html
>>>>>>
>>>>>> http://gnuradio.org/redmine/projects/gnuradio/wiki/ControlPort
>>>>>>
>>>>>>
>>>>>> ControlPort was reintroduced just after the 3.7.7 release so we had
>>>>>> time to
>>>>>> test it, but it will be available in the upcoming 3.7.8 release. The
>>>>>> manual
>>>>>> page linked above is from our weekly development builds.
>>>>>>
>>>>>> This points you to two apps that are installed with ControlPort:
>>>>>> gr-perf-monitorx and gr-ctrlport-monitor. Other good places to look
>>>>>> for
>>>>>> usage is in our QA code. Look in gr-blocks
>>>>>> for qa_cpp_py_binding.py, qa_cpp_py_binding_set.py,
>>>>>> and qa_ctrlport_probes.py.
>>>>>>
>>>>>> Tom
>>>>>>
>>>>>>
>>>>>>
>>>>> ControlPort is written in python ?
>>>>>
>>>>> When I ran qa_ctrlport_probes.py. I got a segmentation fault first
>>>>> time. Then I ran the other two qa codes they passed successfully without
>>>

Re: [Discuss-gnuradio] ControlPort 3.7.8rc1

[bob wole]

On Thu, Aug 6, 2015 at 6:36 PM, Tom Rondeau  wrote:

> On Thu, Aug 6, 2015 at 1:24 AM, bob wole  wrote:
>
>>
>>
>> On Wed, Aug 5, 2015 at 6:46 PM, Tom Rondeau  wrote:
>>
>>> On Wed, Aug 5, 2015 at 1:21 AM, bob wole  wrote:
>>>
>>>>
>>>> > There is a directory
>>>>> > gnuradio-runtime/python/gnuradio/ctrlport
>>>>> >
>>>>> >
>>>>> > where you in controlport related stuff.
>>>>> >
>>>>> > - - Volker
>>>>> >
>>>>> >
>>>>> > Am 04.08.2015 um 10:09 schrieb Jeon:
>>>>> >
>>>>> > Dear Bob,
>>>>> >
>>>>> > A few months ago, I've asked a similar question (
>>>>> > <
>>>>> http://lists.gnu.org/archive/html/discuss-gnuradio/2015-06/msg00197.html
>>>>> >
>>>>> >
>>>>> http://lists.gnu.org/archive/html/discuss-gnuradio/2015-06/msg00197.html
>>>>> )
>>>>> >
>>>>> > and Tom gave me his paper in SIGCOMM.
>>>>> >
>>>>> > Inspecting GNU Radio Applications with ControlPort and Performance
>>>>> Counters
>>>>> > Thomas Rondeau, Tim O?Shea, and Nathan Goergen
>>>>> >
>>>>> > You can get one in
>>>>> http://conferences.sigcomm.org/sigcomm/2013/srif.php
>>>>> >
>>>>> > It does not fully describe how it can be used, though, through this
>>>>> you
>>>>> > can get a hint.
>>>>> >
>>>>> > Regards,
>>>>> > Jeon.
>>>>> >
>>>>> > 2015-08-04 16:36 GMT+09:00 bob wole :
>>>>> >
>>>>> >> Ubuntu 14.04 64-bit
>>>>> >>
>>>>> >> I just installed frest gnuradio 3.7.8rc1 with control port enabled.
>>>>> I
>>>>> >> fetched gnuradio using
>>>>> >>
>>>>> >> git clone --recursive https://github.com/gnuradio/gnuradio.git
>>>>> >>
>>>>> >>
>>>>> >>  Gnuradio enabled component shows
>>>>> >>
>>>>> >> * gr-ctrlport
>>>>> >> * * thrift
>>>>> >>
>>>>> >> However, I do not see any *gr-ctrlport directory *inside the
>>>>> gnuradio
>>>>> >> directory. Where is the source code for control port? Also there
>>>>> are no
>>>>> >> examples for using control port.
>>>>> >>
>>>>> >> --
>>>>> >> Bob
>>>>> >>
>>>>> >
>>>>> You can find more information on these two pages:
>>>>>
>>>>> http://jenkins.gnuradio.org/manual/doxygen/page_ctrlport.html
>>>>>
>>>>> http://gnuradio.org/redmine/projects/gnuradio/wiki/ControlPort
>>>>>
>>>>>
>>>>> ControlPort was reintroduced just after the 3.7.7 release so we had
>>>>> time to
>>>>> test it, but it will be available in the upcoming 3.7.8 release. The
>>>>> manual
>>>>> page linked above is from our weekly development builds.
>>>>>
>>>>> This points you to two apps that are installed with ControlPort:
>>>>> gr-perf-monitorx and gr-ctrlport-monitor. Other good places to look for
>>>>> usage is in our QA code. Look in gr-blocks
>>>>> for qa_cpp_py_binding.py, qa_cpp_py_binding_set.py,
>>>>> and qa_ctrlport_probes.py.
>>>>>
>>>>> Tom
>>>>>
>>>>>
>>>>>
>>>> ControlPort is written in python ?
>>>>
>>>> When I ran qa_ctrlport_probes.py. I got a segmentation fault first
>>>> time. Then I ran the other two qa codes they passed successfully without
>>>> any core dump. When I ran qa_ctrlport_probes.py again it passed
>>>> successfully.
>>>>
>>>> sdr@sdr-dev:~/gr_examples$ ./qa_ctrlport_probes.py
>>>> INFO: Apache Thrift: -h sdr-dev -p 57403
>>>> .
>>>> --
>>>> Ran 5 tests in 0.509s
>>>>
>>>> OK
>>>> *Segmentation fault (core dumped)*
>>&

Re: [Discuss-gnuradio] gr-perf-monitorx Error

[bob wole]

On Thu, Aug 6, 2015 at 6:36 PM, Tom Rondeau  wrote:

> On Thu, Aug 6, 2015 at 1:12 AM, bob wole  wrote:
>
>>
>>
>> On Wed, Aug 5, 2015 at 6:44 PM, Tom Rondeau  wrote:
>>
>>> On Wed, Aug 5, 2015 at 4:47 AM, bob wole  wrote:
>>>
>>>>
>>>> I am here again.  I ran "fecapi_async_decoders.grc" with controlport
>>>> performance moniter on. I made a new config.conf file in ~/.gnuradio and
>>>> added following lines to it
>>>>
>>>> [ControlPort]
>>>> on = True
>>>> edges_list = True
>>>> [PerfCounters]
>>>> on = True
>>>> export = True
>>>>
>>>>
>>>>
>>>> When I ran the flowgraph I got the following error
>>>> Executing:
>>>> "/home/sdr/gr_examples/gr_fec_def_ex/fecapi_async_decoders.py"
>>>>
>>>> Using Volk machine: avx_64_mmx_orc
>>>> ControlPort Monitor running.
>>>> INFO: Apache Thrift: -h sdr-dev -p 50883
>>>> monitor::endpoints() = -h sdr-dev -p 50883
>>>> running: ['gr-perf-monitorx', 'sdr-dev', '50883']
>>>> Traceback (most recent call last):
>>>>   File "/usr/local/bin/gr-perf-monitorx", line 902, in 
>>>> MyApp(sys.argv)
>>>>   File "/usr/local/bin/gr-perf-monitorx", line 897, in __init__
>>>> GNURadioControlPortClient(args, 'thrift', self.run,
>>>> QtGui.QApplication(sys.argv).exec_)
>>>>   File
>>>> "/usr/local/lib/python2.7/dist-packages/gnuradio/ctrlport/GNURadioControlPortClient.py",
>>>> line 125, in __init__
>>>> callback(self.client)
>>>>   File "/usr/local/bin/gr-perf-monitorx", line 900, in run
>>>> MAINWindow(client).show()
>>>>   File "/usr/local/bin/gr-perf-monitorx", line 70, in __init__
>>>> self.newCon(radioclient)
>>>>   File "/usr/local/bin/gr-perf-monitorx", line 84, in newCon
>>>> child = MForm(self.radioclient, len(self.conns), self, dialogprompt
>>>> = not csomeBool)
>>>>   File "/usr/local/bin/gr-perf-monitorx", line 776, in __init__
>>>> self.pos = nx.graphviz_layout(self.G);
>>>>   File
>>>> "/usr/local/lib/python2.7/dist-packages/networkx-1.10-py2.7.egg/networkx/drawing/nx_pydot.py",
>>>> line 257, in graphviz_layout
>>>> return pydot_layout(G=G,prog=prog,root=root,**kwds)
>>>>   File
>>>> "/usr/local/lib/python2.7/dist-packages/networkx-1.10-py2.7.egg/networkx/drawing/nx_pydot.py",
>>>> line 271, in pydot_layout
>>>> pydot = load_pydot()
>>>>   File
>>>> "/usr/local/lib/python2.7/dist-packages/networkx-1.10-py2.7.egg/networkx/drawing/nx_pydot.py",
>>>> line 47, in load_pydot
>>>> raise ImportError(msg)
>>>> ImportError: pydot could not be loaded: http://code.google.com/p/pydot/
>>>>
>>>> I have gnruadio 3.7.8rc1 with networkx1.10 and matplotlib. Also I am on
>>>> ubuntu 14.04.
>>>>
>>>>
>>>> --
>>>> Bob
>>>>
>>>
>>> Did you try to install pydot?
>>>
>>> sudo apt-get install python-pydot
>>>
>>> Tom
>>>
>>>
>>
>> Hi,
>>
>> Thanks, after installing pydot, the flowgraph is working fine. A warning
>> though, but I think that can be ignored?
>>
>>  WARN: asynchronous message buffer overflowing, dropping message
>>
>
> Right, that's just a warning.
>
>
>> There is one thing more. I clicked somewhere in the graph view of
>> performance monitor and following error came, I tried to replicate it but I
>> was not successful.
>>
>> Traceback (most recent call last):
>>   File "/usr/lib/pymodules/python2.7/matplotlib/backends/backend_qt4.py",
>> line 299, in resizeEvent
>> self.draw()
>>   File
>> "/usr/lib/pymodules/python2.7/matplotlib/backends/backend_qt4agg.py", line
>> 155, in draw
>> self.update()
>> RuntimeError: wrapped C/C++ object of type FigureCanvasQTAgg has been
>> deleted
>> ctrlport.monitor received shutdown signal
>> calling stop on shutdown
>> calling stop on shutdown
>> pure virtual method called
>> terminate called without an active exception
>>
>> --
>> Bob
>>
>
> I've worked on this problem, but it only affected me on the Runtime or
> Buffer graphs, not the main canvas. I think something changed in the
> plotting tools since we last had this running. But I can no longer
> replicate the problem, so hopefully it's rare and we can nail down the
> problem later.
>
> Tom
>
>
> Right, I too couldn't replicate it. Thanks



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

Re: [Discuss-gnuradio] FEC GnuRadio 3.7.8rc1 Error

[bob wole]

On Thu, Aug 6, 2015 at 12:44 AM, Tom Rondeau  wrote:

> On Wed, Aug 5, 2015 at 2:07 AM, bob wole  wrote:
>
>> Ubuntu 14.04 64-bit
>> Gnuradio 3.7.8rc1
>>
>>
>> I am running this flowgraph "fecapi_async_to_stream.grc" that comes with
>> gr-fec. After running for a while following error always show up
>>
>> 
>> 
>> DEBUG: 16384, 560, 272
>> DEBUG: 16384, 560, 272
>> FATAL: Missing a required length tag on port 0 at item #14965440
>> thread[thread-per-block[7]: ]: Missing
>> length tag.
>>
>> The only thing that changes is the item#.
>> Testing further 
>>
>>
>> --
>> Bob
>>
>
> Bob,
>
> You led us down a buggy path on that one. This, I'm pretty sure, is
> related to Richard Bell's problem for a few weeks ago where adding a time
> sink caused problems in his data stream. I have to say, I kind of dismissed
> that as impossible, but nope, it's a real problem.
>
> The problem isn't with the GUI sinks; you can replace them with null sinks
> and you get the same problem. It's a race condition in our tag pruning
> method that was changed in 3.7.6. We have a patch that we're putting in now
> that will be part of 3.7.8.
>
> The patch goes backwards a bit to how tag pruning was originally done.
> However, with the map, we no longer have to restart the iterator at begin()
> like we used to, and we can terminate early, so this should still be much
> faster than the original.
>
> Tom
>
>
>
Tom,

Thanks for the update. Which block exactly is causing this? Should I wait
for version 3.7.8 then?


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

Re: [Discuss-gnuradio] ControlPort 3.7.8rc1

[bob wole]

On Wed, Aug 5, 2015 at 6:46 PM, Tom Rondeau  wrote:

> On Wed, Aug 5, 2015 at 1:21 AM, bob wole  wrote:
>
>>
>> > There is a directory
>>> > gnuradio-runtime/python/gnuradio/ctrlport
>>> >
>>> >
>>> > where you in controlport related stuff.
>>> >
>>> > - - Volker
>>> >
>>> >
>>> > Am 04.08.2015 um 10:09 schrieb Jeon:
>>> >
>>> > Dear Bob,
>>> >
>>> > A few months ago, I've asked a similar question (
>>> > <
>>> http://lists.gnu.org/archive/html/discuss-gnuradio/2015-06/msg00197.html
>>> >
>>> >
>>> http://lists.gnu.org/archive/html/discuss-gnuradio/2015-06/msg00197.html
>>> )
>>> >
>>> > and Tom gave me his paper in SIGCOMM.
>>> >
>>> > Inspecting GNU Radio Applications with ControlPort and Performance
>>> Counters
>>> > Thomas Rondeau, Tim O?Shea, and Nathan Goergen
>>> >
>>> > You can get one in
>>> http://conferences.sigcomm.org/sigcomm/2013/srif.php
>>> >
>>> > It does not fully describe how it can be used, though, through this you
>>> > can get a hint.
>>> >
>>> > Regards,
>>> > Jeon.
>>> >
>>> > 2015-08-04 16:36 GMT+09:00 bob wole :
>>> >
>>> >> Ubuntu 14.04 64-bit
>>> >>
>>> >> I just installed frest gnuradio 3.7.8rc1 with control port enabled. I
>>> >> fetched gnuradio using
>>> >>
>>> >> git clone --recursive https://github.com/gnuradio/gnuradio.git
>>> >>
>>> >>
>>> >>  Gnuradio enabled component shows
>>> >>
>>> >> * gr-ctrlport
>>> >> * * thrift
>>> >>
>>> >> However, I do not see any *gr-ctrlport directory *inside the gnuradio
>>> >> directory. Where is the source code for control port? Also there are
>>> no
>>> >> examples for using control port.
>>> >>
>>> >> --
>>> >> Bob
>>> >>
>>> >
>>> You can find more information on these two pages:
>>>
>>> http://jenkins.gnuradio.org/manual/doxygen/page_ctrlport.html
>>>
>>> http://gnuradio.org/redmine/projects/gnuradio/wiki/ControlPort
>>>
>>>
>>> ControlPort was reintroduced just after the 3.7.7 release so we had time
>>> to
>>> test it, but it will be available in the upcoming 3.7.8 release. The
>>> manual
>>> page linked above is from our weekly development builds.
>>>
>>> This points you to two apps that are installed with ControlPort:
>>> gr-perf-monitorx and gr-ctrlport-monitor. Other good places to look for
>>> usage is in our QA code. Look in gr-blocks
>>> for qa_cpp_py_binding.py, qa_cpp_py_binding_set.py,
>>> and qa_ctrlport_probes.py.
>>>
>>> Tom
>>>
>>>
>>>
>> ControlPort is written in python ?
>>
>> When I ran qa_ctrlport_probes.py. I got a segmentation fault first time.
>> Then I ran the other two qa codes they passed successfully without any core
>> dump. When I ran qa_ctrlport_probes.py again it passed successfully.
>>
>> sdr@sdr-dev:~/gr_examples$ ./qa_ctrlport_probes.py
>> INFO: Apache Thrift: -h sdr-dev -p 57403
>> .
>> --
>> Ran 5 tests in 0.509s
>>
>> OK
>> *Segmentation fault (core dumped)*
>>
>> sdr@sdr-dev:~/gr_examples$ ./qa_cpp_py_binding.py
>> INFO: Apache Thrift: -h sdr-dev -p 35595
>> ..
>> --
>> Ran 2 tests in 0.105s
>>
>> OK
>>
>> sdr@sdr-dev:~/gr_examples$ ./qa_cpp_py_binding_set.py
>> INFO: Apache Thrift: -h sdr-dev -p 38301
>> ..
>> --
>> Ran 2 tests in 0.134s
>>
>> OK
>>
>> sdr@sdr-dev:~/gr_examples$ ./qa_ctrlport_probes.py
>> INFO: Apache Thrift: -h sdr-dev -p 38644
>> .
>> --
>> Ran 5 tests in 0.511s
>>
>> OK
>> sdr@sdr-dev:~/gr_examples$ ./qa_ctrlport_probes.py
>> INFO: Apache Thrift: -h sdr-dev -p 48394
>> .
>> --
>> Ran 5 tests in 0.510s
>>
>> OK
>>
>>
>> What could be the cause?  I thought I should share because it is a new
>> release and is in testing stage.
>>
>>
>> --
>> Bob
>>
>
> There is a bug in Thrift 0.9.2 that I'm going to guess is the cause of
> that seg fault. See our notes on building Thrift and the patch that we have
> for it:
>
> http://gnuradio.org/redmine/projects/gnuradio/wiki/ControlPort
>
> I believe that patch has been accepted, but after the 0.9.2 release.
>
> Tom
>
>

I am going to apply the patch to thrift. Should I remove and reinstall
gnruadio too after applying patch.


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

Re: [Discuss-gnuradio] gr-perf-monitorx Error

[bob wole]

On Wed, Aug 5, 2015 at 6:44 PM, Tom Rondeau  wrote:

> On Wed, Aug 5, 2015 at 4:47 AM, bob wole  wrote:
>
>>
>> I am here again.  I ran "fecapi_async_decoders.grc" with controlport
>> performance moniter on. I made a new config.conf file in ~/.gnuradio and
>> added following lines to it
>>
>> [ControlPort]
>> on = True
>> edges_list = True
>> [PerfCounters]
>> on = True
>> export = True
>>
>>
>>
>> When I ran the flowgraph I got the following error
>>
>> Executing: "/home/sdr/gr_examples/gr_fec_def_ex/fecapi_async_decoders.py"
>>
>> Using Volk machine: avx_64_mmx_orc
>> ControlPort Monitor running.
>> INFO: Apache Thrift: -h sdr-dev -p 50883
>> monitor::endpoints() = -h sdr-dev -p 50883
>> running: ['gr-perf-monitorx', 'sdr-dev', '50883']
>> Traceback (most recent call last):
>>   File "/usr/local/bin/gr-perf-monitorx", line 902, in 
>> MyApp(sys.argv)
>>   File "/usr/local/bin/gr-perf-monitorx", line 897, in __init__
>> GNURadioControlPortClient(args, 'thrift', self.run,
>> QtGui.QApplication(sys.argv).exec_)
>>   File
>> "/usr/local/lib/python2.7/dist-packages/gnuradio/ctrlport/GNURadioControlPortClient.py",
>> line 125, in __init__
>> callback(self.client)
>>   File "/usr/local/bin/gr-perf-monitorx", line 900, in run
>> MAINWindow(client).show()
>>   File "/usr/local/bin/gr-perf-monitorx", line 70, in __init__
>> self.newCon(radioclient)
>>   File "/usr/local/bin/gr-perf-monitorx", line 84, in newCon
>> child = MForm(self.radioclient, len(self.conns), self, dialogprompt =
>> not csomeBool)
>>   File "/usr/local/bin/gr-perf-monitorx", line 776, in __init__
>> self.pos = nx.graphviz_layout(self.G);
>>   File
>> "/usr/local/lib/python2.7/dist-packages/networkx-1.10-py2.7.egg/networkx/drawing/nx_pydot.py",
>> line 257, in graphviz_layout
>> return pydot_layout(G=G,prog=prog,root=root,**kwds)
>>   File
>> "/usr/local/lib/python2.7/dist-packages/networkx-1.10-py2.7.egg/networkx/drawing/nx_pydot.py",
>> line 271, in pydot_layout
>> pydot = load_pydot()
>>   File
>> "/usr/local/lib/python2.7/dist-packages/networkx-1.10-py2.7.egg/networkx/drawing/nx_pydot.py",
>> line 47, in load_pydot
>> raise ImportError(msg)
>> ImportError: pydot could not be loaded: http://code.google.com/p/pydot/
>>
>> I have gnruadio 3.7.8rc1 with networkx1.10 and matplotlib. Also I am on
>> ubuntu 14.04.
>>
>>
>> --
>> Bob
>>
>
> Did you try to install pydot?
>
> sudo apt-get install python-pydot
>
> Tom
>
>

Hi,

Thanks, after installing pydot, the flowgraph is working fine. A warning
though, but I think that can be ignored?

 WARN: asynchronous message buffer overflowing, dropping message

There is one thing more. I clicked somewhere in the graph view of
performance monitor and following error came, I tried to replicate it but I
was not successful.

Traceback (most recent call last):
  File "/usr/lib/pymodules/python2.7/matplotlib/backends/backend_qt4.py",
line 299, in resizeEvent
self.draw()
  File
"/usr/lib/pymodules/python2.7/matplotlib/backends/backend_qt4agg.py", line
155, in draw
self.update()
RuntimeError: wrapped C/C++ object of type FigureCanvasQTAgg has been
deleted
ctrlport.monitor received shutdown signal
calling stop on shutdown
calling stop on shutdown
pure virtual method called
terminate called without an active exception

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

[Discuss-gnuradio] gr-perf-monitorx Error

[bob wole]

I am here again.  I ran "fecapi_async_decoders.grc" with controlport
performance moniter on. I made a new config.conf file in ~/.gnuradio and
added following lines to it

[ControlPort]
on = True
edges_list = True
[PerfCounters]
on = True
export = True



When I ran the flowgraph I got the following error

Executing: "/home/sdr/gr_examples/gr_fec_def_ex/fecapi_async_decoders.py"

Using Volk machine: avx_64_mmx_orc
ControlPort Monitor running.
INFO: Apache Thrift: -h sdr-dev -p 50883
monitor::endpoints() = -h sdr-dev -p 50883
running: ['gr-perf-monitorx', 'sdr-dev', '50883']
Traceback (most recent call last):
  File "/usr/local/bin/gr-perf-monitorx", line 902, in 
MyApp(sys.argv)
  File "/usr/local/bin/gr-perf-monitorx", line 897, in __init__
GNURadioControlPortClient(args, 'thrift', self.run,
QtGui.QApplication(sys.argv).exec_)
  File
"/usr/local/lib/python2.7/dist-packages/gnuradio/ctrlport/GNURadioControlPortClient.py",
line 125, in __init__
callback(self.client)
  File "/usr/local/bin/gr-perf-monitorx", line 900, in run
MAINWindow(client).show()
  File "/usr/local/bin/gr-perf-monitorx", line 70, in __init__
self.newCon(radioclient)
  File "/usr/local/bin/gr-perf-monitorx", line 84, in newCon
child = MForm(self.radioclient, len(self.conns), self, dialogprompt =
not csomeBool)
  File "/usr/local/bin/gr-perf-monitorx", line 776, in __init__
self.pos = nx.graphviz_layout(self.G);
  File
"/usr/local/lib/python2.7/dist-packages/networkx-1.10-py2.7.egg/networkx/drawing/nx_pydot.py",
line 257, in graphviz_layout
return pydot_layout(G=G,prog=prog,root=root,**kwds)
  File
"/usr/local/lib/python2.7/dist-packages/networkx-1.10-py2.7.egg/networkx/drawing/nx_pydot.py",
line 271, in pydot_layout
pydot = load_pydot()
  File
"/usr/local/lib/python2.7/dist-packages/networkx-1.10-py2.7.egg/networkx/drawing/nx_pydot.py",
line 47, in load_pydot
raise ImportError(msg)
ImportError: pydot could not be loaded: http://code.google.com/p/pydot/

I have gnruadio 3.7.8rc1 with networkx1.10 and matplotlib. Also I am on
ubuntu 14.04.


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

[Discuss-gnuradio] FEC GnuRadio 3.7.8rc1 Error

[bob wole]

Ubuntu 14.04 64-bit
Gnuradio 3.7.8rc1


I am running this flowgraph "fecapi_async_to_stream.grc" that comes with
gr-fec. After running for a while following error always show up



DEBUG: 16384, 560, 272
DEBUG: 16384, 560, 272
FATAL: Missing a required length tag on port 0 at item #14965440
thread[thread-per-block[7]: ]: Missing length
tag.

The only thing that changes is the item#.
Testing further 


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

Re: [Discuss-gnuradio] ControlPort 3.7.8rc1

[bob wole]

> > There is a directory
> > gnuradio-runtime/python/gnuradio/ctrlport
> >
> >
> > where you in controlport related stuff.
> >
> > - - Volker
> >
> >
> > Am 04.08.2015 um 10:09 schrieb Jeon:
> >
> > Dear Bob,
> >
> > A few months ago, I've asked a similar question (
> > <
> http://lists.gnu.org/archive/html/discuss-gnuradio/2015-06/msg00197.html>
> > http://lists.gnu.org/archive/html/discuss-gnuradio/2015-06/msg00197.html
> )
> >
> > and Tom gave me his paper in SIGCOMM.
> >
> > Inspecting GNU Radio Applications with ControlPort and Performance
> Counters
> > Thomas Rondeau, Tim O?Shea, and Nathan Goergen
> >
> > You can get one in http://conferences.sigcomm.org/sigcomm/2013/srif.php
> >
> > It does not fully describe how it can be used, though, through this you
> > can get a hint.
> >
> > Regards,
> > Jeon.
> >
> > 2015-08-04 16:36 GMT+09:00 bob wole :
> >
> >> Ubuntu 14.04 64-bit
> >>
> >> I just installed frest gnuradio 3.7.8rc1 with control port enabled. I
> >> fetched gnuradio using
> >>
> >> git clone --recursive https://github.com/gnuradio/gnuradio.git
> >>
> >>
> >>  Gnuradio enabled component shows
> >>
> >> * gr-ctrlport
> >> * * thrift
> >>
> >> However, I do not see any *gr-ctrlport directory *inside the gnuradio
> >> directory. Where is the source code for control port? Also there are no
> >> examples for using control port.
> >>
> >> --
> >> Bob
> >>
> >
> You can find more information on these two pages:
>
> http://jenkins.gnuradio.org/manual/doxygen/page_ctrlport.html
>
> http://gnuradio.org/redmine/projects/gnuradio/wiki/ControlPort
>
>
> ControlPort was reintroduced just after the 3.7.7 release so we had time to
> test it, but it will be available in the upcoming 3.7.8 release. The manual
> page linked above is from our weekly development builds.
>
> This points you to two apps that are installed with ControlPort:
> gr-perf-monitorx and gr-ctrlport-monitor. Other good places to look for
> usage is in our QA code. Look in gr-blocks
> for qa_cpp_py_binding.py, qa_cpp_py_binding_set.py,
> and qa_ctrlport_probes.py.
>
> Tom
>
>
>
ControlPort is written in python ?

When I ran qa_ctrlport_probes.py. I got a segmentation fault first time.
Then I ran the other two qa codes they passed successfully without any core
dump. When I ran qa_ctrlport_probes.py again it passed successfully.

sdr@sdr-dev:~/gr_examples$ ./qa_ctrlport_probes.py
INFO: Apache Thrift: -h sdr-dev -p 57403
.
--
Ran 5 tests in 0.509s

OK
*Segmentation fault (core dumped)*

sdr@sdr-dev:~/gr_examples$ ./qa_cpp_py_binding.py
INFO: Apache Thrift: -h sdr-dev -p 35595
..
--
Ran 2 tests in 0.105s

OK

sdr@sdr-dev:~/gr_examples$ ./qa_cpp_py_binding_set.py
INFO: Apache Thrift: -h sdr-dev -p 38301
..
--
Ran 2 tests in 0.134s

OK

sdr@sdr-dev:~/gr_examples$ ./qa_ctrlport_probes.py
INFO: Apache Thrift: -h sdr-dev -p 38644
.
--
Ran 5 tests in 0.511s

OK
sdr@sdr-dev:~/gr_examples$ ./qa_ctrlport_probes.py
INFO: Apache Thrift: -h sdr-dev -p 48394
.
--
Ran 5 tests in 0.510s

OK


What could be the cause?  I thought I should share because it is a new
release and is in testing stage.


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

[Discuss-gnuradio] ControlPort 3.7.8rc1

[bob wole]

Ubuntu 14.04 64-bit

I just installed frest gnuradio 3.7.8rc1 with control port enabled. I
fetched gnuradio using

git clone --recursive https://github.com/gnuradio/gnuradio.git


 Gnuradio enabled component shows

* gr-ctrlport
* * thrift

However, I do not see any *gr-ctrlport directory *inside the gnuradio
directory. Where is the source code for control port? Also there are no
examples for using control port.

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

Re: [Discuss-gnuradio] Memory issues

[bob wole]

Marcus,

Certainly a type. Since Maricus did not mention any hardware sink I was
just reminding him to add a throttle block if it is not there :)

--
Bob

On Thu, Jul 30, 2015 at 11:13 AM, Marcus Müller 
wrote:

> Hi Bob,
>
> Sorry I have to contradict here: when working with hardware, you should
> generally *never* use a throttle block. Maybe that was just a typo in your
> mail?
>
> The reason is that the throttle blocks sole job is to call sleep functions
> for long enough to press the average rate of samples going through the
> throttle block is the set rate. Now, in a world where latency doesn't count
> and all clocks are identical, that's not a problem. However, in practice,
> this means that throttle might block for a relatively long time, when the
> numbers of samples it got in one work iteration are large. In the meantime,
> the downstream hardware might have run dry on samples, even if the throttle
> rate is higher than the sink's sampling rate!
>
> Also, with rates produced by your computer's clock and the oscillator of a
> hardware sink, one has to be a little faster than the other, which leads to
> under or overflow problems sooner or later.
>
> However, in the pure simulation case, I agree, you should add a throttle
> and see whether it helps.
>
> Best regards,
> Marcus
>
> Am 30. Juli 2015 07:10:13 MESZ, schrieb bob wole :
>
>> Maricus,
>>
>> Does your flowgraph involves aany hardware sink e.g USRP, audio ? If try
>> adding a throttle if you are not already doing it.
>>
>> --
>> Bob
>>
>>
>>
>>> Hi Marius,
>>>
>>> good question!
>>> Now, typically, you'd use tools like valgrind to figure that out. I
>>> haven't noticed a memory leak in GNU Radio itself, but it's absolutely
>>> possible that something like PMTs do not get freed etc, and we didn't
>>> notice how this could happen.
>>> If you need additional things to look for:
>>> * do you have something like a vector that stores e.g. messages that
>>> come in?
>>> * what's the failure mode of your application? Is it killed by the
>>> Out-of-Memory killer, or do you get into a situation where it crashes
>>> because of e.g. stack overflow?
>>>
>>> Best regards,
>>> Marcus
>>>
>>> On 29.07.2015 15:57, Marius Cachelin wrote:
>>> > Hi all,
>>> >
>>> > I am writing because I have some misunderstood concerning how memory
>>> > is used in GNURadio.
>>> >
>>> > I developed a transmitter which can be split into 5 parts :
>>> >- MAC Encoder : read PDU data from TUNTAP
>>> >- HEADER Prefixer : add header before each PDU Data
>>> >- PREAMBLE prefixer : add preamble before each PDU Data
>>> >- MODULATOR : Performing BPSK/QPSK
>>> >- FIR Interp : Pulse shape
>>> >
>>> > My question is : when I run my transmitter, I can see in HTOP that the
>>> > memory (%MEM) used by my transmitter increase. The increasing is
>>> > relatively slow, but the is an issue because I can't keep using my
>>> > transmitter after a while.
>>> >
>>> > I have checked all my blocks. All memory allocations are freed, and
>>> > all my objetcs (new...) are deleted.
>>> >
>>> > So, how the memory can increase if I do not allocate extra memory and
>>> > free all memory?
>>> >
>>> > Thanks you in advance.
>>> >
>>> > --
>>> > *CACHELIN Marius*
>>> > /Ing?nieur Syst?mes, R?seaux et T?l?communications/
>>> > marius.cache...@gmail.com <mailto:marius.cache...@gmail.com
>>>
>> --
>>
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Memory issues

[bob wole]

Maricus,

Does your flowgraph involves aany hardware sink e.g USRP, audio ? If try
adding a throttle if you are not already doing it.

--
Bob



> Hi Marius,
>
> good question!
> Now, typically, you'd use tools like valgrind to figure that out. I
> haven't noticed a memory leak in GNU Radio itself, but it's absolutely
> possible that something like PMTs do not get freed etc, and we didn't
> notice how this could happen.
> If you need additional things to look for:
> * do you have something like a vector that stores e.g. messages that
> come in?
> * what's the failure mode of your application? Is it killed by the
> Out-of-Memory killer, or do you get into a situation where it crashes
> because of e.g. stack overflow?
>
> Best regards,
> Marcus
>
> On 29.07.2015 15:57, Marius Cachelin wrote:
> > Hi all,
> >
> > I am writing because I have some misunderstood concerning how memory
> > is used in GNURadio.
> >
> > I developed a transmitter which can be split into 5 parts :
> >- MAC Encoder : read PDU data from TUNTAP
> >- HEADER Prefixer : add header before each PDU Data
> >- PREAMBLE prefixer : add preamble before each PDU Data
> >- MODULATOR : Performing BPSK/QPSK
> >- FIR Interp : Pulse shape
> >
> > My question is : when I run my transmitter, I can see in HTOP that the
> > memory (%MEM) used by my transmitter increase. The increasing is
> > relatively slow, but the is an issue because I can't keep using my
> > transmitter after a while.
> >
> > I have checked all my blocks. All memory allocations are freed, and
> > all my objetcs (new...) are deleted.
> >
> > So, how the memory can increase if I do not allocate extra memory and
> > free all memory?
> >
> > Thanks you in advance.
> >
> > --
> > *CACHELIN Marius*
> > /Ing?nieur Syst?mes, R?seaux et T?l?communications/
> > marius.cache...@gmail.com 
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Errors in FEC gnruadio

[bob wole]

On Sat, Jul 4, 2015 at 8:35 PM, bob wole  wrote:

> Hi list,
>
> I was not getting reply on the previous thread so I though to start a new
> thread.
>
> gnuradio version 3.7.7.1
> ubunutu 14.04 32-bit
>
> I am trying to use gr-fec and I am having issues running examples located
> in gnuradio/gr-fec/examples/
>
>
> When I run ber_test.grc I get following error
>
> Using Volk machine: avx_32_mmx_orc
> Traceback (most recent call last):
>   File "/home/gnuradio/gr-fec/examples/ber_test.py", line 267, in 
> tb = ber_test()
>   File "/home/gnuradio/gr-fec/examples/ber_test.py", line 159, in __init__
> self.fec_extended_encoder_0 =
> fec.extended_encoder(encoder_obj_list=enc, threading='capillary',
> puncpat="puncpat")
>   File
> "/usr/local/lib/python2.7/dist-packages/gnuradio/fec/extended_encoder.py",
> line 64, in __init__
> self.blocks.append(fec.puncture_bb(len(puncpat),
> read_bitlist(puncpat), 0))
>   File "/usr/local/lib/python2.7/dist-packages/gnuradio/fec/bitflip.py",
> line 47, in read_bitlist
> if int(bitlist[i]) == 1:
> ValueError: invalid literal for int() with base 10: 'p'
>
> >>> Done (return code 1)
>
>
> When I run tpc_ber_curve_gen.grc I get following error
>
> Using Volk machine: avx_32_mmx_orc
> Traceback (most recent call last):
>   File "/home/gnuradio/gr-fec/examples/tpc_ber_curve_gen.py", line 450, in
> 
> tb.start()
>   File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py",
> line 106, in start
> top_block_start_unlocked(self._impl, max_noutput_items)
>   File
> "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py", line
> 4860, in top_block_start_unlocked
> return _runtime_swig.top_block_start_unlocked(*args, **kwargs)
> RuntimeError: boost::thread_resource_error: Resource temporarily
> unavailable
>
> >>> Done
>
> fecapi_async_decoders.grc runs without any errors.
>
> Any Ideas what could be wrong ?
>
> --
> Bob
>
>
Hi,

Can I get any reply/feedback on this please???


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

[Discuss-gnuradio] Errors in FEC gnruadio

[bob wole]

Hi list,

I was not getting reply on the previous thread so I though to start a new
thread.

gnuradio version 3.7.7.1
ubunutu 14.04 32-bit

I am trying to use gr-fec and I am having issues running examples located
in gnuradio/gr-fec/examples/


When I run ber_test.grc I get following error

Using Volk machine: avx_32_mmx_orc
Traceback (most recent call last):
  File "/home/gnuradio/gr-fec/examples/ber_test.py", line 267, in 
tb = ber_test()
  File "/home/gnuradio/gr-fec/examples/ber_test.py", line 159, in __init__
self.fec_extended_encoder_0 =
fec.extended_encoder(encoder_obj_list=enc, threading='capillary',
puncpat="puncpat")
  File
"/usr/local/lib/python2.7/dist-packages/gnuradio/fec/extended_encoder.py",
line 64, in __init__
self.blocks.append(fec.puncture_bb(len(puncpat), read_bitlist(puncpat),
0))
  File "/usr/local/lib/python2.7/dist-packages/gnuradio/fec/bitflip.py",
line 47, in read_bitlist
if int(bitlist[i]) == 1:
ValueError: invalid literal for int() with base 10: 'p'

>>> Done (return code 1)


When I run tpc_ber_curve_gen.grc I get following error

Using Volk machine: avx_32_mmx_orc
Traceback (most recent call last):
  File "/home/gnuradio/gr-fec/examples/tpc_ber_curve_gen.py", line 450, in

tb.start()
  File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py",
line 106, in start
top_block_start_unlocked(self._impl, max_noutput_items)
  File
"/usr/local/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py", line
4860, in top_block_start_unlocked
return _runtime_swig.top_block_start_unlocked(*args, **kwargs)
RuntimeError: boost::thread_resource_error: Resource temporarily unavailable

>>> Done

fecapi_async_decoders.grc runs without any errors.

Any Ideas what could be wrong ?

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

Re: [Discuss-gnuradio] FEC in gnruadio

[bob wole]

On Thu, Jul 2, 2015 at 8:10 PM, bob wole  wrote:

>
>
> On Tue, Jun 30, 2015 at 2:00 PM, bob wole  wrote:
>
>>
>>
>> On Tue, Jun 16, 2015 at 11:45 PM, bob wole  wrote:
>>
>>>
>>>
>>> On Tue, Jun 16, 2015 at 11:41 PM, Tom Rondeau  wrote:
>>>
>>>> On Tue, Jun 16, 2015 at 1:03 PM, bob wole  wrote:
>>>>
>>>>>
>>>>>
>>>>>> On 16.06.2015 08:26, bob wole wrote:
>>>>>> > Hi,
>>>>>> >
>>>>>> > I just stared working on FEC in gnuradio. I found that there is
>>>>>> > gr-fec.  I want to know that which literature , books/papers, was
>>>>>> > followed during the implementation of the gr-fec so that I can go
>>>>>> > through the c++ implementation more productively and add
>>>>>> > something.
>>>>>> >
>>>>>> >
>>>>>> > -- Bob
>>>>>> >
>>>>>> -
>>>>>>
>>>>>> > Hi,
>>>>>> >
>>>>>> > I just stared working on FEC in gnuradio. I found that there is
>>>>>> gr-fec.  I
>>>>>> > want to know that which literature , books/papers, was followed
>>>>>> during the
>>>>>> > implementation of the gr-fec so that I can go through the c++
>>>>>> > implementation more productively and add something.
>>>>>> >
>>>>>> >
>>>>>> > --
>>>>>> > Bob
>>>>>> >
>>>>>>
>>>>>> Hi Bob,
>>>>>>
>>>>>> Have a look at the manual. The API itself is quite well described I
>>>>>> think:
>>>>>>
>>>>>> http://gnuradio.org/doc/doxygen/page_fec.html
>>>>>>
>>>>>> It doesn't cover the very recently added TPC and LDPC implementations.
>>>>>> http://gnuradio.org/doc/doxygen/classgr_1_1fec_1_1ldpc__decoder.html
>>>>>> http://gnuradio.org/doc/doxygen/classgr_1_1fec_1_1ldpc__decoder.html
>>>>>> http://gnuradio.org/doc/doxygen/classgr_1_1fec_1_1tpc__encoder.html
>>>>>> http://gnuradio.org/doc/doxygen/classgr_1_1fec_1_1tpc__decoder.html
>>>>>>
>>>>>> Those could use work on their documentation.
>>>>>>
>>>>>> We're also about to merge in another approach to LDPC encoding and
>>>>>> decoding
>>>>>> based on Tracie Perez's GSoC work. You can see the wip branch here:
>>>>>>
>>>>>> https://github.com/trondeau/gnuradio/tree/fec/ldpc_methods
>>>>>>
>>>>>> And the GSoC presentations:
>>>>>> http://www.trondeau.com/grcon2013-presentations#gsoc-perez
>>>>>> http://www.trondeau.com/grcon2013-presentations#gsoc-manu
>>>>>>
>>>>>> Johannes Demel is working on polar codes this summer.
>>>>>>
>>>>>> What's your particular interest in FEC? Are you looking to use it or
>>>>>> implement other codes not already in gr-fec? For the FEC API itself,
>>>>>> there
>>>>>> is no other reference than the manual page and a presentation from the
>>>>>> original author at our GRCons:
>>>>>>
>>>>>> http://www.trondeau.com/grcon14-presentations#tut-mccarthy
>>>>>> http://www.trondeau.com/grcon2013-presentations#tut-mccarthy
>>>>>>
>>>>>> Tom
>>>>>>
>>>>>
>>>>> Hi Tom,
>>>>>
>>>>> Thanks for the links. I am targeting Turbo Codes mainly for short
>>>>> frame size. I found one presentation on turbo codes
>>>>>
>>>>>
>>>>> http://gnuradio.squarespace.com/storage/grcon14/presentations/Sep18_02_Karra_TurboCodes.pdf
>>>>>
>>>>> but I could not find its source code in gnuradio. Are Turbo codes
>>>>> implemented in gnuradio? if yes, in which version can I find it? One more
>>>>> question, I am targeting short frame length burst, currently which FEC in
>>>>> gnuradio can give me best gain in this case?
>>>>>
>>>>> --
>>>>> Bob
>>>>>
>>>>
>>>> Bob,
>>>>

Re: [Discuss-gnuradio] FEC in gnruadio

[bob wole]

On Tue, Jun 30, 2015 at 2:00 PM, bob wole  wrote:

>
>
> On Tue, Jun 16, 2015 at 11:45 PM, bob wole  wrote:
>
>>
>>
>> On Tue, Jun 16, 2015 at 11:41 PM, Tom Rondeau  wrote:
>>
>>> On Tue, Jun 16, 2015 at 1:03 PM, bob wole  wrote:
>>>
>>>>
>>>>
>>>>> On 16.06.2015 08:26, bob wole wrote:
>>>>> > Hi,
>>>>> >
>>>>> > I just stared working on FEC in gnuradio. I found that there is
>>>>> > gr-fec.  I want to know that which literature , books/papers, was
>>>>> > followed during the implementation of the gr-fec so that I can go
>>>>> > through the c++ implementation more productively and add
>>>>> > something.
>>>>> >
>>>>> >
>>>>> > -- Bob
>>>>> >
>>>>> -
>>>>>
>>>>> > Hi,
>>>>> >
>>>>> > I just stared working on FEC in gnuradio. I found that there is
>>>>> gr-fec.  I
>>>>> > want to know that which literature , books/papers, was followed
>>>>> during the
>>>>> > implementation of the gr-fec so that I can go through the c++
>>>>> > implementation more productively and add something.
>>>>> >
>>>>> >
>>>>> > --
>>>>> > Bob
>>>>> >
>>>>>
>>>>> Hi Bob,
>>>>>
>>>>> Have a look at the manual. The API itself is quite well described I
>>>>> think:
>>>>>
>>>>> http://gnuradio.org/doc/doxygen/page_fec.html
>>>>>
>>>>> It doesn't cover the very recently added TPC and LDPC implementations.
>>>>> http://gnuradio.org/doc/doxygen/classgr_1_1fec_1_1ldpc__decoder.html
>>>>> http://gnuradio.org/doc/doxygen/classgr_1_1fec_1_1ldpc__decoder.html
>>>>> http://gnuradio.org/doc/doxygen/classgr_1_1fec_1_1tpc__encoder.html
>>>>> http://gnuradio.org/doc/doxygen/classgr_1_1fec_1_1tpc__decoder.html
>>>>>
>>>>> Those could use work on their documentation.
>>>>>
>>>>> We're also about to merge in another approach to LDPC encoding and
>>>>> decoding
>>>>> based on Tracie Perez's GSoC work. You can see the wip branch here:
>>>>>
>>>>> https://github.com/trondeau/gnuradio/tree/fec/ldpc_methods
>>>>>
>>>>> And the GSoC presentations:
>>>>> http://www.trondeau.com/grcon2013-presentations#gsoc-perez
>>>>> http://www.trondeau.com/grcon2013-presentations#gsoc-manu
>>>>>
>>>>> Johannes Demel is working on polar codes this summer.
>>>>>
>>>>> What's your particular interest in FEC? Are you looking to use it or
>>>>> implement other codes not already in gr-fec? For the FEC API itself,
>>>>> there
>>>>> is no other reference than the manual page and a presentation from the
>>>>> original author at our GRCons:
>>>>>
>>>>> http://www.trondeau.com/grcon14-presentations#tut-mccarthy
>>>>> http://www.trondeau.com/grcon2013-presentations#tut-mccarthy
>>>>>
>>>>> Tom
>>>>>
>>>>
>>>> Hi Tom,
>>>>
>>>> Thanks for the links. I am targeting Turbo Codes mainly for short frame
>>>> size. I found one presentation on turbo codes
>>>>
>>>>
>>>> http://gnuradio.squarespace.com/storage/grcon14/presentations/Sep18_02_Karra_TurboCodes.pdf
>>>>
>>>> but I could not find its source code in gnuradio. Are Turbo codes
>>>> implemented in gnuradio? if yes, in which version can I find it? One more
>>>> question, I am targeting short frame length burst, currently which FEC in
>>>> gnuradio can give me best gain in this case?
>>>>
>>>> --
>>>> Bob
>>>>
>>>
>>> Bob,
>>>
>>> Yes, Kiran's TPC work has been integrated as of 3.7.7.1. (I even pointed
>>> out the links to the manual pages for the tpc_encoder and tpc_decoder
>>> above.)
>>>
>>> Tom
>>>
>>>
>> Thanks Tom,
>>
>> I am going to test them soon for my bursty system :) Lets see how it
>> works.
>>
>> --
>> Bob
>>
>
> Hi list,
>
> gnura

Re: [Discuss-gnuradio] FEC in gnruadio

[bob wole]

On Tue, Jun 16, 2015 at 11:45 PM, bob wole  wrote:

>
>
> On Tue, Jun 16, 2015 at 11:41 PM, Tom Rondeau  wrote:
>
>> On Tue, Jun 16, 2015 at 1:03 PM, bob wole  wrote:
>>
>>>
>>>
>>>> On 16.06.2015 08:26, bob wole wrote:
>>>> > Hi,
>>>> >
>>>> > I just stared working on FEC in gnuradio. I found that there is
>>>> > gr-fec.  I want to know that which literature , books/papers, was
>>>> > followed during the implementation of the gr-fec so that I can go
>>>> > through the c++ implementation more productively and add
>>>> > something.
>>>> >
>>>> >
>>>> > -- Bob
>>>> >
>>>> -
>>>>
>>>> > Hi,
>>>> >
>>>> > I just stared working on FEC in gnuradio. I found that there is
>>>> gr-fec.  I
>>>> > want to know that which literature , books/papers, was followed
>>>> during the
>>>> > implementation of the gr-fec so that I can go through the c++
>>>> > implementation more productively and add something.
>>>> >
>>>> >
>>>> > --
>>>> > Bob
>>>> >
>>>>
>>>> Hi Bob,
>>>>
>>>> Have a look at the manual. The API itself is quite well described I
>>>> think:
>>>>
>>>> http://gnuradio.org/doc/doxygen/page_fec.html
>>>>
>>>> It doesn't cover the very recently added TPC and LDPC implementations.
>>>> http://gnuradio.org/doc/doxygen/classgr_1_1fec_1_1ldpc__decoder.html
>>>> http://gnuradio.org/doc/doxygen/classgr_1_1fec_1_1ldpc__decoder.html
>>>> http://gnuradio.org/doc/doxygen/classgr_1_1fec_1_1tpc__encoder.html
>>>> http://gnuradio.org/doc/doxygen/classgr_1_1fec_1_1tpc__decoder.html
>>>>
>>>> Those could use work on their documentation.
>>>>
>>>> We're also about to merge in another approach to LDPC encoding and
>>>> decoding
>>>> based on Tracie Perez's GSoC work. You can see the wip branch here:
>>>>
>>>> https://github.com/trondeau/gnuradio/tree/fec/ldpc_methods
>>>>
>>>> And the GSoC presentations:
>>>> http://www.trondeau.com/grcon2013-presentations#gsoc-perez
>>>> http://www.trondeau.com/grcon2013-presentations#gsoc-manu
>>>>
>>>> Johannes Demel is working on polar codes this summer.
>>>>
>>>> What's your particular interest in FEC? Are you looking to use it or
>>>> implement other codes not already in gr-fec? For the FEC API itself,
>>>> there
>>>> is no other reference than the manual page and a presentation from the
>>>> original author at our GRCons:
>>>>
>>>> http://www.trondeau.com/grcon14-presentations#tut-mccarthy
>>>> http://www.trondeau.com/grcon2013-presentations#tut-mccarthy
>>>>
>>>> Tom
>>>>
>>>
>>> Hi Tom,
>>>
>>> Thanks for the links. I am targeting Turbo Codes mainly for short frame
>>> size. I found one presentation on turbo codes
>>>
>>>
>>> http://gnuradio.squarespace.com/storage/grcon14/presentations/Sep18_02_Karra_TurboCodes.pdf
>>>
>>> but I could not find its source code in gnuradio. Are Turbo codes
>>> implemented in gnuradio? if yes, in which version can I find it? One more
>>> question, I am targeting short frame length burst, currently which FEC in
>>> gnuradio can give me best gain in this case?
>>>
>>> --
>>> Bob
>>>
>>
>> Bob,
>>
>> Yes, Kiran's TPC work has been integrated as of 3.7.7.1. (I even pointed
>> out the links to the manual pages for the tpc_encoder and tpc_decoder
>> above.)
>>
>> Tom
>>
>>
> Thanks Tom,
>
> I am going to test them soon for my bursty system :) Lets see how it works.
>
> --
> Bob
>

Hi list,

gnuradio version 3.7.7.1
ubunutu 14.04 32-bit

I am trying to use gr-fec and I am having issues running examples located
in gnuradio/gr-fec/examples/


When I run ber_test.grc I get following error

Using Volk machine: avx_32_mmx_orc
Traceback (most recent call last):
  File "/home/gnuradio/gr-fec/examples/ber_test.py", line 267, in 
tb = ber_test()
  File "/home/gnuradio/gr-fec/examples/ber_test.py", line 159, in __init__
self.fec_extended_encoder_0 =
fec.extended_encoder(encoder_obj

Re: [Discuss-gnuradio] FEC in gnruadio

[bob wole]

On Tue, Jun 16, 2015 at 11:41 PM, Tom Rondeau  wrote:

> On Tue, Jun 16, 2015 at 1:03 PM, bob wole  wrote:
>
>>
>>
>>> On 16.06.2015 08:26, bob wole wrote:
>>> > Hi,
>>> >
>>> > I just stared working on FEC in gnuradio. I found that there is
>>> > gr-fec.  I want to know that which literature , books/papers, was
>>> > followed during the implementation of the gr-fec so that I can go
>>> > through the c++ implementation more productively and add
>>> > something.
>>> >
>>> >
>>> > -- Bob
>>> >
>>> -
>>>
>>> > Hi,
>>> >
>>> > I just stared working on FEC in gnuradio. I found that there is
>>> gr-fec.  I
>>> > want to know that which literature , books/papers, was followed during
>>> the
>>> > implementation of the gr-fec so that I can go through the c++
>>> > implementation more productively and add something.
>>> >
>>> >
>>> > --
>>> > Bob
>>> >
>>>
>>> Hi Bob,
>>>
>>> Have a look at the manual. The API itself is quite well described I
>>> think:
>>>
>>> http://gnuradio.org/doc/doxygen/page_fec.html
>>>
>>> It doesn't cover the very recently added TPC and LDPC implementations.
>>> http://gnuradio.org/doc/doxygen/classgr_1_1fec_1_1ldpc__decoder.html
>>> http://gnuradio.org/doc/doxygen/classgr_1_1fec_1_1ldpc__decoder.html
>>> http://gnuradio.org/doc/doxygen/classgr_1_1fec_1_1tpc__encoder.html
>>> http://gnuradio.org/doc/doxygen/classgr_1_1fec_1_1tpc__decoder.html
>>>
>>> Those could use work on their documentation.
>>>
>>> We're also about to merge in another approach to LDPC encoding and
>>> decoding
>>> based on Tracie Perez's GSoC work. You can see the wip branch here:
>>>
>>> https://github.com/trondeau/gnuradio/tree/fec/ldpc_methods
>>>
>>> And the GSoC presentations:
>>> http://www.trondeau.com/grcon2013-presentations#gsoc-perez
>>> http://www.trondeau.com/grcon2013-presentations#gsoc-manu
>>>
>>> Johannes Demel is working on polar codes this summer.
>>>
>>> What's your particular interest in FEC? Are you looking to use it or
>>> implement other codes not already in gr-fec? For the FEC API itself,
>>> there
>>> is no other reference than the manual page and a presentation from the
>>> original author at our GRCons:
>>>
>>> http://www.trondeau.com/grcon14-presentations#tut-mccarthy
>>> http://www.trondeau.com/grcon2013-presentations#tut-mccarthy
>>>
>>> Tom
>>>
>>
>> Hi Tom,
>>
>> Thanks for the links. I am targeting Turbo Codes mainly for short frame
>> size. I found one presentation on turbo codes
>>
>>
>> http://gnuradio.squarespace.com/storage/grcon14/presentations/Sep18_02_Karra_TurboCodes.pdf
>>
>> but I could not find its source code in gnuradio. Are Turbo codes
>> implemented in gnuradio? if yes, in which version can I find it? One more
>> question, I am targeting short frame length burst, currently which FEC in
>> gnuradio can give me best gain in this case?
>>
>> --
>> Bob
>>
>
> Bob,
>
> Yes, Kiran's TPC work has been integrated as of 3.7.7.1. (I even pointed
> out the links to the manual pages for the tpc_encoder and tpc_decoder
> above.)
>
> Tom
>
>
Thanks Tom,

I am going to test them soon for my bursty system :) Lets see how it works.

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

Re: [Discuss-gnuradio] FEC in gnruadio

[bob wole]

>
> On 16.06.2015 08:26, bob wole wrote:
> > Hi,
> >
> > I just stared working on FEC in gnuradio. I found that there is
> > gr-fec.  I want to know that which literature , books/papers, was
> > followed during the implementation of the gr-fec so that I can go
> > through the c++ implementation more productively and add
> > something.
> >
> >
> > -- Bob
> >
> -
>
> > Hi,
> >
> > I just stared working on FEC in gnuradio. I found that there is gr-fec.
> I
> > want to know that which literature , books/papers, was followed during
> the
> > implementation of the gr-fec so that I can go through the c++
> > implementation more productively and add something.
> >
> >
> > --
> > Bob
> >
>
> Hi Bob,
>
> Have a look at the manual. The API itself is quite well described I think:
>
> http://gnuradio.org/doc/doxygen/page_fec.html
>
> It doesn't cover the very recently added TPC and LDPC implementations.
> http://gnuradio.org/doc/doxygen/classgr_1_1fec_1_1ldpc__decoder.html
> http://gnuradio.org/doc/doxygen/classgr_1_1fec_1_1ldpc__decoder.html
> http://gnuradio.org/doc/doxygen/classgr_1_1fec_1_1tpc__encoder.html
> http://gnuradio.org/doc/doxygen/classgr_1_1fec_1_1tpc__decoder.html
>
> Those could use work on their documentation.
>
> We're also about to merge in another approach to LDPC encoding and decoding
> based on Tracie Perez's GSoC work. You can see the wip branch here:
>
> https://github.com/trondeau/gnuradio/tree/fec/ldpc_methods
>
> And the GSoC presentations:
> http://www.trondeau.com/grcon2013-presentations#gsoc-perez
> http://www.trondeau.com/grcon2013-presentations#gsoc-manu
>
> Johannes Demel is working on polar codes this summer.
>
> What's your particular interest in FEC? Are you looking to use it or
> implement other codes not already in gr-fec? For the FEC API itself, there
> is no other reference than the manual page and a presentation from the
> original author at our GRCons:
>
> http://www.trondeau.com/grcon14-presentations#tut-mccarthy
> http://www.trondeau.com/grcon2013-presentations#tut-mccarthy
>
> Tom
>

Hi Tom,

Thanks for the links. I am targeting Turbo Codes mainly for short frame
size. I found one presentation on turbo codes

http://gnuradio.squarespace.com/storage/grcon14/presentations/Sep18_02_Karra_TurboCodes.pdf

but I could not find its source code in gnuradio. Are Turbo codes
implemented in gnuradio? if yes, in which version can I find it? One more
question, I am targeting short frame length burst, currently which FEC in
gnuradio can give me best gain in this case?

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

[Discuss-gnuradio] FEC in gnruadio

[bob wole]

Hi,

I just stared working on FEC in gnuradio. I found that there is gr-fec.  I
want to know that which literature , books/papers, was followed during the
implementation of the gr-fec so that I can go through the c++
implementation more productively and add something.


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

[Discuss-gnuradio] Python block help

[bob wole]

Hi list,

I am writing a custom python block that should take complex input, check
magnitude of incoming samples and if the magnitude is greater than a
threshold value, the block should pass that sample otherwise the block just
drop the samples. As this is an arbitrary ratio block I derived it from
gr.block and set_auto_consume(False).

However I get intermittent zeros in output stream of my custom block. Below
is the code

from gnuradio import gr
import gnuradio.extras
import math
import numpy as np


class sdr_pass_valid(gr.block):
"""
"""
def __init__(self,threshold):
gr.block.__init__(
self,
name = "VALID",
in_sig = [np.complex64],
out_sig = [np.complex64],
)
self.set_auto_consume(False)

self.threshold =  threshold
def forecast (self,noutput_items,ninput_items_required):
for i in range(len(ninput_items_required)):
ninput_items_required[i] = noutput_items

def work(self, input_items, output_items):

in0 = input_items[0][:len(output_items[0])]
out0= output_items[0]
nread = self.nitems_read(0) #number of items read on port 0
ninput_items = len(in0)
j=0
for i in range(0,ninput_items):
if np.absolute(in0[i]) >= self.threshold :
out0[j] = in0[i]
j = j + 1
self.consume(0,ninput_items)
self.produce(0,len(out0))
return 0


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

Re: [Discuss-gnuradio] [USRP-users] Switching and high spike in spectrum

[bob wole]

On 10/29/2014 01:54 PM, bob wole via USRP-users wrote:
> >
> > USRPN210r4 with SBX
> >
> > I am observing a strong spike at the center of the receive spectrum
> > when I start burst transmission.
> >
> > My top flowgraph contains following two hierarchical blocks
> >  1) A transmitter flow graph with (tx_time, tx_sob, tx_eob)
> >  2) A receiver flow graph
> >
> > When I run top flowgrpah (without transmitting anything) and observe
> > the FFT of the received signal the spectrum does not contain high
> > spike in the center.
> >
> > But as soon as I start transmitting in burst mode I see a very high
> > spike in center of the received signal FFT spectrum. It looks like LO
> > (transmitter or receiver ) is being received? Which one is it ? And
> > why is it happening?  How can I avoid it because it is affecting my
> > packets.
> >
> > When I apply the offset in digital using DDC/DUC, the spike moves out
> > of the band.
> >
> >
> > --
> > Bob
> >
> >
> > ___
> > USRP-users mailing list
> > usrp-us...@lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> That spike in the middle is a consequence of using direct conversion in
> both the RX and TX paths--it'll be there in both to some degree.
>
> You can use offset-tuning to move the DC offset outside your passband:
>
> http://files.ettus.com/manual/page_general.html
>
>
> In built-for-a-particular-purpose radios, there will also be undesired
> LO leakage and mixing products--those are generally dealt with using an
>application/band-specific filter to eliminate them.  For
> general-purpose SDRs, that isn't possible to do "as manufactured", you
> have to deal
>with RF hygiene and plumbing issues yourself.
>
> So, moving the LO leakage outside your passband is part of the
> picture--use offset tuning for that.  Then, if you have "this won't meet
>our hygiene requirements", you have to look at filtering.
>
> Another thing you really should do is to run the calibration utilities,
> which will attempt to balance I/Q amplitude and phase, which can improve
>some of these issues, but not, usually, eliminate them entirely.
>
>
>
Yes, I know that LO leakage/DC offset is an issue present in direct
conversion receiver. But as I mentioned earlier, the received spectrum
looks fine (a very little spike at DC around -70dB) while the burst
transmission is not running. The spike becomes much more significant ( high
spike at DC -20dB) when burst transmission (tx_time,tx_eob, tx_sob )
starts  and all the spectrum just shifts up and down with it. I am using
TX/RX antenna in both usrp source and usrp sink. I want to know why the
burst transmission is affecting the received spectrum on the same node.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Switching and high spike in spectrum

[bob wole]

USRPN210r4 with SBX

I am observing a strong spike at the center of the receive spectrum when I
start burst transmission.

My top flowgraph contains following two hierarchical blocks
 1) A transmitter flow graph with (tx_time, tx_sob, tx_eob)
 2) A receiver flow graph

When I run top flowgrpah (without transmitting anything) and observe the
FFT of the received signal the spectrum does not contain high spike in the
center.

But as soon as I start transmitting in burst mode I see a very high spike
in center of the received signal FFT spectrum. It looks like LO
(transmitter or receiver ) is being received? Which one is it ? And why is
it happening?  How can I avoid it because it is affecting my packets.

When I apply the offset in digital using DDC/DUC, the spike moves out of
the band.


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

Re: [Discuss-gnuradio] Bypass work function

[bob wole]

Well, in my case the tx/rx would not be stationary, so the channel is not
quite.

--
Bob



> If you can tolerate the stream stopping, use Power Squelch. Otherwise,
> time to dive in and follow Tom's advice from May - disable the CMA taps
> update loop when there's no signal. This whole idea assumes you have a
> mostly quiet channel, stationary tx/rx, etc. Interested to hear what you
> come up with.
>
> - Jeff
>
> On 10/01/2014 11:24 PM, bob wole wrote:
> > I applied this and this is useful in condition when you do not want to
> > process noise, because it is being multiplied by zero when there is no
> > signal. But I want that CMA taps remain unchanged when there is no
> > signal or just noise. In the above scenario CMA taps change due to
> > presence of noise, because it tries to equalize noise as well.  Thanks
> > for your comment.
> >
> > --
> > Bob
> >
> > On Mon, Sep 29, 2014 at 7:19 PM, Jeff Long  > <mailto:willco...@gmail.com>> wrote:
> >
> > Try using a "threshold" off the "mag squared" and feed that into a
> > multiplier after block2 (with appropriate type adapters). As long as
> > block2 doesn't have a huge delay or do rate changes, this should
> work.
> >
> > - Jeff
> >
> > On 09/29/2014 10:23 AM, bob wole wrote:
> > > Hi thanks for your comment. block2 is the gnuradio "CMA equalizer
> > > block". I want the CMA block to remain quiet when there is no
> signal of
> > > interest.
> > >
> > > Bob
> > >
> > >
> > > Bob,
> > >
> > > Saw this the other day, but there isn't a lot to go on here.
> If block2
> > > is your own, you can make it do the bypass. You can also use
> some of the
> > > logic blocks and a multiplier depending on what you're doing.
> There
> > > isn't really a concept of on-the-fly switching in GNU Radio.
> > >
> > > - Jeff
> > >
> > > On 09/26/2014 01:02 PM, bob wole wrote:
> > >  >
> > >  > People, any ideas on it?
> > >  >
> > >  > --
> > >  > Bob
> > >  >
> > >  > On Wed, Sep 24, 2014 at 12:04 PM, bob wole <
> bnw...@gmail.com <mailto:bnw...@gmail.com>
> > > <mailto:bnw...@gmail.com <mailto:bnw...@gmail.com>>
> >  >  > <mailto:bnw...@gmail.com <mailto:bnw...@gmail.com>
> > <mailto:bnw...@gmail.com <mailto:bnw...@gmail.com>>>> wrote:
> >  >  >
> >  >  >   I have following flowgraph:
> >  >  >
> >  >  >
> >  >  >
> >   usrp_source--->>probe_mag_squared_block>block2--->block3
> >  >  >
> >  >  > What I want to do is that I want to bypass the "work"
> > function of
> >  >  > block2 when the threshold level of probe_mag_squared
> > reaches.
> >  > I do
> >  >  > not want to stop(), lock(), disconnect the flow graph.
> > Is this
> >  >  > possible using stream tags, or message passing etc ?
> > Any example
> >  >  > code would be nice.
> >  >  >
> >  >  > --
> >  >  > Bob
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Bypass work function

[bob wole]

I applied this and this is useful in condition when you do not want to
process noise, because it is being multiplied by zero when there is no
signal. But I want that CMA taps remain unchanged when there is no signal
or just noise. In the above scenario CMA taps change due to presence of
noise, because it tries to equalize noise as well.  Thanks for your
comment.

--
Bob

On Mon, Sep 29, 2014 at 7:19 PM, Jeff Long  wrote:

> Try using a "threshold" off the "mag squared" and feed that into a
> multiplier after block2 (with appropriate type adapters). As long as
> block2 doesn't have a huge delay or do rate changes, this should work.
>
> - Jeff
>
> On 09/29/2014 10:23 AM, bob wole wrote:
> > Hi thanks for your comment. block2 is the gnuradio "CMA equalizer
> > block". I want the CMA block to remain quiet when there is no signal of
> > interest.
> >
> > Bob
> >
> >
> > Bob,
> >
> > Saw this the other day, but there isn't a lot to go on here. If
> block2
> > is your own, you can make it do the bypass. You can also use some of
> the
> > logic blocks and a multiplier depending on what you're doing. There
> > isn't really a concept of on-the-fly switching in GNU Radio.
> >
> > - Jeff
> >
> > On 09/26/2014 01:02 PM, bob wole wrote:
> >  >
> >  > People, any ideas on it?
> >  >
> >  > --
> >  > Bob
> >  >
> >  > On Wed, Sep 24, 2014 at 12:04 PM, bob wole  > <mailto:bnw...@gmail.com>
> >  > <mailto:bnw...@gmail.com <mailto:bnw...@gmail.com>>> wrote:
> >  >
> >  >   I have following flowgraph:
> >  >
> >  >
> >  > usrp_source--->>probe_mag_squared_block>block2--->block3
> >  >
> >  > What I want to do is that I want to bypass the "work"
> function of
> >  > block2 when the threshold level of probe_mag_squared reaches.
> > I do
> >  > not want to stop(), lock(), disconnect the flow graph. Is this
> >  > possible using stream tags, or message passing etc ? Any
> example
> >  > code would be nice.
> >  >
> >  > --
> >  > Bob
> >
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Bypass work function

[bob wole]

Hi thanks for your comment. block2 is the gnuradio "CMA equalizer block". I
want the CMA block to remain quiet when there is no signal of interest.

Bob


Bob,
>
> Saw this the other day, but there isn't a lot to go on here. If block2
> is your own, you can make it do the bypass. You can also use some of the
> logic blocks and a multiplier depending on what you're doing. There
> isn't really a concept of on-the-fly switching in GNU Radio.
>
> - Jeff
>
> On 09/26/2014 01:02 PM, bob wole wrote:
> >
> > People, any ideas on it?
> >
> > --
> > Bob
> >
> > On Wed, Sep 24, 2014 at 12:04 PM, bob wole  > <mailto:bnw...@gmail.com>> wrote:
> >
> >   I have following flowgraph:
> >
> >
> > usrp_source--->>probe_mag_squared_block>block2--->block3
> >
> > What I want to do is that I want to bypass the "work" function of
> > block2 when the threshold level of probe_mag_squared reaches. I do
> > not want to stop(), lock(), disconnect the flow graph. Is this
> > possible using stream tags, or message passing etc ? Any example
> > code would be nice.
> >
> > --
> > Bob
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Bypass work function

[bob wole]

People, any ideas on it?

--
Bob

On Wed, Sep 24, 2014 at 12:04 PM, bob wole  wrote:

>  I have following flowgraph:
>
>
> usrp_source--->>probe_mag_squared_block>block2--->block3
>
> What I want to do is that I want to bypass the "work" function of block2
> when the threshold level of probe_mag_squared reaches. I do not want to
> stop(), lock(), disconnect the flow graph. Is this possible using stream
> tags, or message passing etc ? Any example code would be nice.
>
> --
> Bob
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Bypass work function

[bob wole]

 I have following flowgraph:


usrp_source--->>probe_mag_squared_block>block2--->block3

What I want to do is that I want to bypass the "work" function of block2
when the threshold level of probe_mag_squared reaches. I do not want to
stop(), lock(), disconnect the flow graph. Is this possible using stream
tags, or message passing etc ? Any example code would be nice.

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

Re: [Discuss-gnuradio] tx_time tag accuraccy

[bob wole]

On 06/09/2014 06:05 AM, bob wole wrote:
> > Can I have  a comment on it?
>
> Bob,
>
> we've given you a lot of information on this (see Tom's posts as a
> start). If you still have questions, I recommend you start a new thread
> and post exactly what you need to know and what your requirements are.
>
> M
>


Marting, I got the answer from Tom, clock resolution for checking *tx_time*
tag is 10ns (100MHz clock). Thanks


--
Bob

>
> >
> > --
> > Bob
> >
> > On Thu, Jun 5, 2014 at 11:02 AM, bob wole  > <mailto:bnw...@gmail.com>> wrote:
> >
> > Sorry for not stating the hardware earlier. I am using USRP N210,
> > with RFX2400 and WBX boards.
> >
> > --
> > Bob
> >
> > On Wed, Jun 4, 2014 at 11:07 PM, Marcus Leech  > <mailto:mle...@ripnet.com>> wrote:
> >
> > I don't know the detailed answer, but any such answer will
> > depend very much on which USRP hardware you're talking about.
> >
> > One of the R&D people who deals with the FPGA codebase may be
> > able to give a precise answer, given stated hardware.
> >
> >
> >
> > on Jun 04, 2014, *bob wole*  > <mailto:bnw...@gmail.com>> wrote:
> >
> > Marcus! Thanks for you comment.
> >
> > I think that USRP transmit FIFO is at the start of the DSP
> > chain in FPGA i.e it is prior to both of the interpolation
> > filters? right?  I am not talking about when the burst will
> > be over the air, I want to know when the first sample of the
> > burst will leave the transmit FIFO if it has been tagged as
> > tx_time=X.
> >
> >
> >
> > --
> > Bob
> >
> >
> > On Wed, Jun 4, 2014 at 10:51 PM, Marcus Leech
> > mailto:mle...@ripnet.com>> wrote:
> >
> >     It will depend some on the effective group delay of both
> > the interpolation filters in the the FPGA and the analog
> > group delay of the analog bits of whatever daughtercard
> > you're using.
> >
> > The only way to be sure is to measure...
> >
> >
> > on Jun 04, 2014, *bob wole via USRP-users*
> >  > <mailto:usrp-us...@lists.ettus.com>> wrote:
> >
> > I am using stream tags for the transmission control.
> > I want to know what is the accuracy/precision of the
> > tx_time tag? E.g if I tag a burst A with tx_time=X,
> > then the burst A will come out of the USRP transmit
> > FIFO at X+delta, how large the value of delta could
> > be?
> >
> >
> > --
> > Bob
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] tx_time tag accuraccy

[bob wole]

Hi Tom,

Thanks for your comment. I do not think if I tag a burst with time X, it'll
go out of USRP transmit FIFO at exactly X, there would be  some small delta
involved depending on the clock resolution, and I want to know that delta.
I know that there would be some DSP delays, depending on sample rate, and
analog delays *AFTER* the burst leave transmit buffer.

--
Bob

On Mon, Jun 9, 2014 at 10:05 AM, Tom Tsou  wrote:

> On Wed, Jun 4, 2014 at 2:01 PM, bob wole  wrote:
> > I think that USRP transmit FIFO is at the start of the DSP chain in FPGA
> i.e
> > it is prior to both of the interpolation filters? right?  I am not
> talking
> > about when the burst will be over the air, I want to know when the first
> > sample of the burst will leave the transmit FIFO if it has been tagged as
> > tx_time=X.
>
> If you tag a burst with time X, that burst will be released from the
> device buffer at time X - assuming the burst arrives at the device
> before time X. After time X, there will be a sample rate dependent
> delay and a fixed analog group delay before the burst can be observed
> at the antenna output.
>
> In other words, a burst tagged to transmit at time X will leave the
> buffer at time X.
>
>   -TT
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] tx_time tag accuraccy

[bob wole]

Can I have  a comment on it?


--
Bob

On Thu, Jun 5, 2014 at 11:02 AM, bob wole  wrote:

> Sorry for not stating the hardware earlier. I am using USRP N210, with
> RFX2400 and WBX boards.
>
> --
> Bob
>
> On Wed, Jun 4, 2014 at 11:07 PM, Marcus Leech  wrote:
>
>> I don't know the detailed answer, but any such answer will depend very
>> much on which USRP hardware you're talking about.
>>
>> One of the R&D people who deals with the FPGA codebase may be able to
>> give a precise answer, given stated hardware.
>>
>>
>>
>>  on Jun 04, 2014, *bob wole*  wrote:
>>
>>  Marcus! Thanks for you comment.
>>
>> I think that USRP transmit FIFO is at the start of the DSP chain in FPGA
>> i.e it is prior to both of the interpolation filters? right?  I am not
>> talking about when the burst will be over the air, I want to know when the
>> first sample of the burst will leave the transmit FIFO if it has been
>> tagged as tx_time=X.
>>
>>
>>
>> --
>> Bob
>>
>>
>> On Wed, Jun 4, 2014 at 10:51 PM, Marcus Leech  wrote:
>>
>>> It will depend some on the effective group delay of both the
>>> interpolation filters in the the FPGA and the analog group delay of the
>>> analog bits of whatever daughtercard you're using.
>>>
>>> The only way to be sure is to measure...
>>>
>>>
>>>   on Jun 04, 2014, *bob wole via USRP-users* 
>>> wrote:
>>>
>>>  I am using stream tags for the transmission control. I want to know
>>> what is the accuracy/precision of the tx_time tag? E.g if I tag a burst A
>>> with tx_time=X, then the burst A will come out of the USRP transmit FIFO at
>>> X+delta, how large the value of delta could be?
>>>
>>>
>>> --
>>> Bob
>>>   --
>>>
>>> ___
>>> USRP-users mailing list
>>> usrp-us...@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] tx_time tag accuraccy

[bob wole]

Sorry for not stating the hardware earlier. I am using USRP N210, with
RFX2400 and WBX boards.

--
Bob

On Wed, Jun 4, 2014 at 11:07 PM, Marcus Leech  wrote:

> I don't know the detailed answer, but any such answer will depend very
> much on which USRP hardware you're talking about.
>
> One of the R&D people who deals with the FPGA codebase may be able to give
> a precise answer, given stated hardware.
>
>
>
>  on Jun 04, 2014, *bob wole*  wrote:
>
>  Marcus! Thanks for you comment.
>
> I think that USRP transmit FIFO is at the start of the DSP chain in FPGA
> i.e it is prior to both of the interpolation filters? right?  I am not
> talking about when the burst will be over the air, I want to know when the
> first sample of the burst will leave the transmit FIFO if it has been
> tagged as tx_time=X.
>
>
>
> --
> Bob
>
>
> On Wed, Jun 4, 2014 at 10:51 PM, Marcus Leech  wrote:
>
>> It will depend some on the effective group delay of both the
>> interpolation filters in the the FPGA and the analog group delay of the
>> analog bits of whatever daughtercard you're using.
>>
>> The only way to be sure is to measure...
>>
>>
>>   on Jun 04, 2014, *bob wole via USRP-users* 
>> wrote:
>>
>>  I am using stream tags for the transmission control. I want to know
>> what is the accuracy/precision of the tx_time tag? E.g if I tag a burst A
>> with tx_time=X, then the burst A will come out of the USRP transmit FIFO at
>> X+delta, how large the value of delta could be?
>>
>>
>> --
>> Bob
>>   --
>>
>> ___
>> USRP-users mailing list
>> usrp-us...@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] tx_time tag accuraccy

[bob wole]

Marcus! Thanks for you comment.

I think that USRP transmit FIFO is at the start of the DSP chain in FPGA
i.e it is prior to both of the interpolation filters? right?  I am not
talking about when the burst will be over the air, I want to know when the
first sample of the burst will leave the transmit FIFO if it has been
tagged as tx_time=X.



--
Bob


On Wed, Jun 4, 2014 at 10:51 PM, Marcus Leech  wrote:

> It will depend some on the effective group delay of both the interpolation
> filters in the the FPGA and the analog group delay of the analog bits of
> whatever daughtercard you're using.
>
> The only way to be sure is to measure...
>
>
>  on Jun 04, 2014, *bob wole via USRP-users* 
> wrote:
>
> I am using stream tags for the transmission control. I want to know what
> is the accuracy/precision of the tx_time tag? E.g if I tag a burst A with
> tx_time=X, then the burst A will come out of the USRP transmit FIFO at
> X+delta, how large the value of delta could be?
>
>
> --
> Bob
>
> --
>
> ___
> USRP-users mailing list
> usrp-us...@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] tx_time tag accuraccy

[bob wole]

I am using stream tags for the transmission control. I want to know what is
the accuracy/precision of the tx_time tag? E.g if I tag a burst A with
tx_time=X, then the burst A will come out of the USRP transmit FIFO at
X+delta, how large the value of delta could be?


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

Re: [Discuss-gnuradio] Equalization class help

[bob wole]

Thanks for your reply Tom. Could I have some  more explanation on it?  if a
training sequence at start of each burst could help in fast convergence for
burst modem?

--
Bob


On Mon, May 12, 2014 at 6:01 AM, Tom Rondeau  wrote:

> On Mon, May 12, 2014 at 5:59 AM, bob wole  wrote:
>
>> I want to work on equalization for ISI removal due to multipaths for
>> burst frequency shift keying system. I found equalizer class in gnruadio, I
>> want to know if somebody used cma_equalizer for the task with success or if
>> I can use it for equalization of burst frequency shift keying system before
>> continuing with it?
>>
>>
>> Thanks
>>
>> --
>> Bob
>>
>
> It'll conceivably work, but the challenge with the CMA equalizer (and the
> LMS-DD equalizer as well) is the long convergence time. Between every
> burst, you're going to lose tracking of the taps, so you might want to
> think of a way to shut down the tap update loop when you're not receiving a
> packet (which involves knowing when that's happening in time to send the
> info to the equalizer). For starters, just use a few taps in the equalizer
> and a gain higher than you would expect to see if you can get it to
> converge to "close enough" early in the burst.
>
> Tom
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Equalization class help

[bob wole]

I want to work on equalization for ISI removal due to multipaths for burst
frequency shift keying system. I found equalizer class in gnruadio, I want
to know if somebody used cma_equalizer for the task with success or if I
can use it for equalization of burst frequency shift keying system before
continuing with it?


Thanks

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

[Discuss-gnuradio] UHD Asyn Msg source help!

[bob wole]

I am trying to use the UHD Asyn Msg source but I am not getting any thing
out of this block. How can I use it? Can somebody please share any existing
flow-graph that demonstrates the block usage.

Thanks,

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

Re: [Discuss-gnuradio] How to best use new GR features for TDMA systems ?

[bob wole]

> I think GNU Radio apps should look a bit like this:
> At the top (think "MAC") blocks pass data as PDUs. The further down you go
> ("PHY"), you'll eventually need regular blocks. Here, tagged streams will
> do what you want.
> I guess gr-easymac was an early demo of this principle, although its
> functionality can now be reproduced with pure GNU Radio. At CEL, we've
> developed a FHSS network using pure GNU Radio, which works quite well
> (someone still needs to release some code, and I hope they're reading this
> :). There will be a presentation on this at FOSDEM, btw.
>
> Also, I've been working on a way to do TDMA using the OFDM blocks (on one
> of my lower-priority branches, though, so don't get too excited right now).
> In principle, the idea is:
> * At MAC level, create a package with a tx time stamp as a PDU
> * Pass this to the OFDM mod. The time stamp will propagate along with the
> length tag, and stay at the front of the streamed packet (this feature was
> merged into GNU Radio a while back and is available in the latest release).
> * The hardware driver should take the streamed packet and the metadata in
> the tags (the tx time, though it could also be *the centre frequency for
> FH*)
> and tx accordingly.
>
Hi MB,
I am using tags (tx_time, tx_eob, tx_sob) for  burst transmission. You
mentioned above that tags can also be used to tell the centre frequency for
FH? Which tag does so ? Is it a custom tag you implemented ?

Thanks,

Bob


> * At the receive side, all we need to do is remember the rx time of samples
> when we do a packet modulation.
>
> There's a couple of things that are hard here: On the TX side, we just hope
> that the packet will reach the hardware in time. What if it doesn't? Well,
> bad luck.
>
> Bottom line: GNU Radio has only recently become capable of doing these
> things. This means we are still in the process of figuring out of how
> exactly to write TDMA PHYs with corresponding MACs, which is a feature that
> we've always wanted and now seems achievable. I guess the more we try out,
> the more we will identify what's missing in order to do this.
>
> MB
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] test correlate and sync block

[bob wole]

I installed a fresh verison of gnuradio 3.7.2.1 and was testing some of the
new features including the "correlate and sync"- A must from burst modems.
I am using the "test_corr_and_sync.grc" example. Constellation and rest of
the output looks fine. However, when I plot the "phase" output of
"polyphase clock sync" its look like during burst time phase does not get
lock. Phase output just keep on changing, please see the attached picture
of phase output. Well, real performance test should include a packet
encoder and decoder etc to evaluate BER. But before trying that I thought I
should try the example that comes with gnuradio, is the phase outputlooks
ok?

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

Re: [Discuss-gnuradio] Installation issue

[bob wole]

On Sun, Dec 15, 2013 at 10:57 PM, Tom Rondeau  wrote:

> On Sun, Dec 15, 2013 at 12:36 PM, bob wole  wrote:
> > I installed gnuradio and UHD using instruction on
> >
> >
> http://gnuradio.org/redmine/projects/gnuradio/wiki/BinaryPackages#Binaries-from-Ettus-Research-Linux-Windows
> >
> > UHD programs are running fine e.g uhd_find _devices. But when I run
> > $ gnuradio-config-info
> > I get following
> > gnuradio-config-info: error while loading shared libraries:
> liblog4cpp.so.5:
> > cannot open shared object file: No such file or directory
> >
> > I have also done sudo ldconfig and my paths are set properly. What could
> be
> > the issue ?
> >
> >
> > Can I use 'build gnuradio' script to install a specific version of
> gnuradio
> > and UHD? If yes, how? What is the recommended way to do this?
> >
> > --
> > bob
>
>
> Do you have log4cpp installed? You can do it using 'apt-get install
> liblog4cpp5-dev". That should sort you out.
>
> It looks like that package might be built with the logger but log4cpp
> is not defined as a dependency. I'll check with our package maintainer
> on this.
>
> Tom
>

Thanks Tom for reply.

sudo apt-get install liblog4cpp5-dev worked for me. I downloaded deb file
from

http://files.ettus.com/binaries/gnuradio/latest_stable/

I am unable to find the source code i.e .cc files for gnuradio blocks.
Where I can  find them? Installing from "deb" does not download the source
code as well?

Also, Its mention on the gnuradio page that build gnuradio script should be
used for newer ubuntu versions. How can I use 'build gnuradio' script to
install a specific version of gnuradio and UHD?

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

Re: [Discuss-gnuradio] Installation issue

[bob wole]

I am using Ubuntu 12.04 LTS 64 bit.


On Sun, Dec 15, 2013 at 9:36 AM, bob wole  wrote:

> I installed gnuradio and UHD using instruction on
>
>
> http://gnuradio.org/redmine/projects/gnuradio/wiki/BinaryPackages#Binaries-from-Ettus-Research-Linux-Windows
>
> UHD programs are running fine e.g uhd_find _devices. But when I run
> $ gnuradio-config-info
> I get following
> gnuradio-config-info: error while loading shared libraries:
> liblog4cpp.so.5: cannot open shared object file: No such file or directory
>
> I have also done sudo ldconfig and my paths are set properly. What could
> be the issue ?
>
>
> Can I use 'build gnuradio' script to install a specific version of
> gnuradio and UHD? If yes, how? What is the recommended way to do this?
>
> --
> bob
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Installation issue

[bob wole]

I installed gnuradio and UHD using instruction on

http://gnuradio.org/redmine/projects/gnuradio/wiki/BinaryPackages#Binaries-from-Ettus-Research-Linux-Windows

UHD programs are running fine e.g uhd_find _devices. But when I run
$ gnuradio-config-info
I get following
gnuradio-config-info: error while loading shared libraries:
liblog4cpp.so.5: cannot open shared object file: No such file or directory

I have also done sudo ldconfig and my paths are set properly. What could be
the issue ?


Can I use 'build gnuradio' script to install a specific version of gnuradio
and UHD? If yes, how? What is the recommended way to do this?

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

Re: [Discuss-gnuradio] Looking for DSSS demodulator

[bob wole]

Thanks Achilleas for explanation,

I'll try with gnuradio 3.7.2 and report back.

--
bob


On Fri, Nov 22, 2013 at 8:30 PM, Achilleas Anastasopoulos  wrote:

> Bob,
>
> As I mentioned in my email, the only application that currently
> runs is the
>
> timing_test.grc
>
> For it to run you need to load the block
>
> chopper_correlator.grc
>
> and compile it in grc so that it gets to your custom grc directory.
>
> Please let me know if you have any issues with this.
> This application contains all the essentials for the cdma system, but it is
> not THE cdma system...
>
> The whole project is built on gnuradio 3.7.2
>
> The remaining apps/blocks for cdma are work-in-progress.
>
> best,
> Achilleas
>
>
>
> On Fri, Nov 22, 2013 at 10:19 AM, bob wole  wrote:
>
>> Great share Achilleas. But I am having problem running it. Quite a few
>> blocks are missing. Please share on what version of GnuRadio was it built
>> against? Did you use custom blocks too?
>>
>> --
>> Bob
>>
>>
>>>
>>> Outstanding!  Thanks for putting in the time to make this happen!
>>>
>>> What version of gnuRadio was it built against?
>>>
>>> @(^.^)@  Ed
>>>
>>>
>>>
>>> On 11/20/13 4:05 PM, Achilleas Anastasopoulos wrote:
>>> > I have been working on a DSSS system for some time now.
>>> > You can find our work-in-progress here:
>>> >
>>> > https://github.com/anastas/gr-cdma.git
>>> >
>>> > A few comments:
>>> >
>>> > this project grew out of the DARPA spectrum challenge:
>>> > our team eventually dropped out of the race because of other time
>>> > commitments but
>>> > I decided to finish up the design and make it publicly available
>>> > since DARPA was generous enough to send us USRPs for testing etc.
>>>
>>>
>>>
>>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Looking for DSSS demodulator

[bob wole]

Great share Achilleas. But I am having problem running it. Quite a few
blocks are missing. Please share on what version of GnuRadio was it built
against? Did you use custom blocks too?

--
Bob


>
> Outstanding!  Thanks for putting in the time to make this happen!
>
> What version of gnuRadio was it built against?
>
> @(^.^)@  Ed
>
>
> On 11/20/13 4:05 PM, Achilleas Anastasopoulos wrote:
> > I have been working on a DSSS system for some time now.
> > You can find our work-in-progress here:
> >
> > https://github.com/anastas/gr-cdma.git
> >
> > A few comments:
> >
> > this project grew out of the DARPA spectrum challenge:
> > our team eventually dropped out of the race because of other time
> > commitments but
> > I decided to finish up the design and make it publicly available
> > since DARPA was generous enough to send us USRPs for testing etc.
>
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] HELP! - Problem with radio application deploy

[bob wole]

Thanks Tom and Marcus for taking time out and explaining things on the
list.

--
Bob


>
> > How do you determine the size of taps? How much of a difference does
> > setting the transition width from 1MHz to 10MHz make?
> >
> Generally, the wider the transition width, the fewer taps.
>
> You can use the "firdes" functions, which is what the low-pass filter
> blocks call in gnuradio, then take their output into a variable and
>have another variable be len(filter).
>
>
> >
> > On Tue, Nov 19, 2013 at 6:40 PM, Marcus D. Leech  > > wrote:
> >
> > I really appreciate the detailed explanation. I tried running
> > gr_filter_design last night and it asked me to install SciPy,
> > which I did not feel like doing at that time. I will try using
> > 1MHz for my band, which may help get rid of the real-time
> > running issue.
> >
> > Again, I appreciate your help with this matter.
> >
> > Let's say you get a filter that's, oh, I dunno, 100 taps long.
> > That filter has to process every sample, so, that's 5e7 X 100 taps,
> or
> >   roughly 5e9 FLOP/second.  Just for that one filter.  And your
> > flow-graph is likely doing other things *and* it's having to get
> > samples
> >   all the way through your network or USB stacks into the
> > application layer as well, call that 100 instructions/sample.  So,
> > that's
> >   5e7 x 100 = 5e9 OPS/second just to get your samples into the
> > application.  You're going to burn-up the cycles on your CPU pretty
> >   quickly at 50Msps, even for doing "trivial" things.
> >
> >
> >
> >
> >
> > --
> > Marcus Leech
> > Principal Investigator
> > Shirleys Bay Radio Astronomy Consortium
> > http://www.sbrac.org
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr_firdes.cc/firdes.cc - window functions - flawe

[bob wole]

Hi Tom and Chris,

Thanks for your detailed guidance on this. I'll try this out.

Bob


On Mon, Oct 7, 2013 at 9:49 PM, KB3CS - Chris  wrote:

> $ git diff v3.6.3 HEAD gr-filter/lib/firdes.cc  (but modified since you
> remain @ v3.6.3)
>
> diff --git a/gr-filter/lib/firdes.cc b/gr-filter/lib/firdes.cc
> index 5c3320d..d55a4ba 100644
> --- a/gr-filter/lib/firdes.cc
> +++ b/gr-filter/lib/firdes.cc
> @@ -746,6 +746,7 @@ namespace gr {
>case WIN_RECTANGULAR:
> for(int n = 0; n < ntaps; n++)
>taps[n] = 1;
> +break;
>
>case WIN_HAMMING:
> for(int n = 0; n < ntaps; n++)
> @@ -774,16 +775,13 @@ namespace gr {
>   double IBeta = 1.0/Izero(beta);
>   double inm1 = 1.0/((double)(ntaps));
>   double temp;
> - //fprintf(stderr, "IBeta = %g; inm1 = %g\n", IBeta, inm1);
>
> - for(int i=0; i -   temp = i * inm1;
> -   //fprintf(stderr, "temp = %g\n", temp);
> -   taps[i] = Izero(beta*sqrt(1.0-temp*temp)) * IBeta;
> -   //fprintf(stderr, "taps[%d] = %g\n", i, taps[i]);
> - }
> + for(int i= 0; i +temp = 2*i*inm1 - 1;
> +taps[i] = Izero(beta*sqrt(1.0-temp*temp)) * IBeta;
> +  }
> }
> -  break;
> +   break;
>
>default:
> throw std::out_of_range("firdes:window: type out of range");
> @@ -804,7 +802,7 @@ namespace gr {
> throw std::out_of_range("firdes check failed: 0 < fa <=
> sampling_freq / 2");
>
>if(transition_width <= 0)
> -   throw std::out_of_range("gr_dirdes check failed: transition_width
> > 0");
> +   throw std::out_of_range("gr_firdes check failed: transition_width
> > 0");
>  }
>
>  void
>
> .. but don't make the #include file changes in your v3.6.3 and you should
> change the version number (VERSION_INFO_MAINT_VERSION) in CMakeLists.txt
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr_firdes.cc/firdes.cc - window functions - flawe

[bob wole]

We installed gnuradio 3.6.3 using gnruadio build script. We can't
change the gnuradio version currently. How can we apply this patch to
our installation. What commands should we run? We don't use git.

--
Bob

 On Sun, Oct 6, 2013 at 12:39 PM, KB3CS - Chris  wrote:
>* (If you just want to cut to the chase, the diff against 3.6.5.1 is attached)*
>
>* How i got here:  Contemplating some filters using gnuradio-companion with a*
>* simple flowgraph (simple enough to describe in words alone).  Noticed the*
>* frequency response with a Rectangular filter was exactly the same as with a*
>* Hamming filter and also the response with a Kaiser filter (while varying*
>* Beta) seemed quite wrong.*
>
>* The flowgraph:  noise source -> throttle -> filter -> FFT*
>* really basic.  used the "convenience" blocks which are wrappers for firdes.*
>
>* After quite a while of scratching my head at the odd results observed, then*
>* checking (and double-checking) Oppenheim[1999] and others, I wrote a little*
>* python to have a direct look at the window function coefficients:*
>
>* #!/usr/bin/env python*
>* from gnuradio import gr, audio*
>* from math import pi*
>
>* sample_rate = 192000*
>* ntaps = 16*
>
>* #channel_coeffs =*
>* gr.firdes.low_pass(1.0,sample_rate,50e3,4e3,gr.firdes.WIN_HAMMING,beta)*
>
>* #print channel_coeffs*
>
>* #channel_coeffs = gr.firdes.low_pass(1.0,10,1,1,gr.firdes.WIN_HAMMING,beta)*
>
>* #print channel_coeffs*
>
>* print "\n\nRectangular window function for {} samples\n".format(ntaps)*
>
>* win_coeffs = gr.firdes.window(gr.firdes.WIN_RECTANGULAR,ntaps,0)*
>
>* print win_coeffs*
>
>* print "\n\nHamming window function for {} samples\n".format(ntaps)*
>
>* win_coeffs = gr.firdes.window(gr.firdes.WIN_HAMMING,ntaps,0)*
>
>* print win_coeffs*
>
>* print "\n\nKaiser window function for {} samples\n".format(ntaps)*
>
>* alpha = 1.0*
>* print "Alpha = {}\n".format(alpha)*
>* win_coeffs = gr.firdes.window(gr.firdes.WIN_KAISER,ntaps,alpha*pi)*
>
>* print win_coeffs*
>
>* alpha = 2.5*
>* print "\nAlpha = {}\n".format(alpha)*
>* win_coeffs = gr.firdes.window(gr.firdes.WIN_KAISER,ntaps,alpha*pi)*
>
>* print win_coeffs*
>
>* alpha = 8.0*
>* print "\nAlpha = {}\n".format(alpha)*
>* win_coeffs = gr.firdes.window(gr.firdes.WIN_KAISER,ntaps,alpha*pi)*
>
>* print win_coeffs*
>
>* alpha = 20.0*
>* print "\nAlpha = {}\n".format(alpha)*
>* win_coeffs = gr.firdes.window(gr.firdes.WIN_KAISER,ntaps,alpha*pi)*
>
>* print win_coeffs*
>
>* print "\nDone\n"*
>
>* .. and here's the essential extract of output from unmodified v3.6.5.1*
>* source:*
>
>* Rectangular window function for 16 samples*
>
>* (0.0799821186066, 0.11976908892393112, 0.23219992220401764,*
>* 0.39785218238830566, 0.5880830883979797, 0.769809265137,*
>* 0.9121478199958801, 0.9899479150772095, 0.9899479150772095,*
>* 0.9121478199958801, 0.769809265137, 0.5880830883979797,*
>* 0.39785218238830566, 0.23219992220401764, 0.11976908892393112,*
>* 0.0799821186066)*
>
>
>* Hamming window function for 16 samples*
>
>* (0.0799821186066, 0.11976908892393112, 0.23219992220401764,*
>* 0.39785218238830566, 0.5880830883979797, 0.769809265137,*
>* 0.9121478199958801, 0.9899479150772095, 0.9899479150772095,*
>* 0.9121478199958801, 0.769809265137, 0.5880830883979797,*
>* 0.39785218238830566, 0.23219992220401764, 0.11976908892393112,*
>* 0.0799821186066)*
>
>
>* Kaiser window function for 16 samples*
>
>* Alpha = 1.0*
>
>* (1.0, 0.9949779510498047, 0.9800193309783936, 0.9554436802864075,*
>* 0.9217740297317505, 0.8797227740287781, 0.8301725387573242,*
>* 0.7741525173187256, 0.712824038696, 0.6473857760429382,*
>* 0.5791705250740051, 0.5094824433326721, 0.43962839245796204,*
>* 0.3708721101284027, 0.3044034540653229, 0.241310253739357)*
>
>
>* ... the Rectangular coefficients aren't right.  And sure, it's really weird*
>* the coefficients are the same as for the Hamming window.  But look at the*
>* Kaiser coefficients!  (this was giving me an awful headache and bothering me*
>* to no end).*
>
>* With a little help from octave and some quick cut-n-pastes, I was now*
>* contemplating graphs of window functions.  The Kaiser window function didn't*
>* look right at all.  It started a 1.0 and tapered toward zero.  No starting*
>* near zero and tapering -up- toward 1.0 present. That can't be right, can it?*
>* Well, no, it can't.  Hmm!*
>
>* Glossing over the many hours it took from the start of this journey to its*
>* conclusion, I present the essential extract of output from v3.6.5.1 source*
>* modified by the diff attached to this message:*
>
>* Rectangular window function for 16 samples*
>
>* (1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0,*
>* 1.0)*
>
>
>* Hamming window function for 16 samples*
>
>* (0.0799821186066, 0.11976908892393112, 0.23219992220401764,*
>* 0.39785218238830566, 0.5880830883979797, 0.769809265137,*
>* 0.9121478199958801, 0.9899479150772095, 0.9899479150772095,*
>* 0.9121478199958801, 0.769

Re: [Discuss-gnuradio] AGC and Dynamic Range of ADC

[bob wole]

On 09/23/2013 11:07 PM, bob wole wrote:

Can somebody please guide me on this ?

Bob


On Fri, Sep 20, 2013 at 4:44 PM, bob wole  wrote:

> I have USRPN210 with WBX and RFX2400. Is there any AGC chip on N210
> motherboard or WBX, RFX2400 before ADC to utilize the dynamic range of ADC
> ? if yes, which one? If not, then won't the varying input signal (for
> example signal from moving object)  to ADC affect the performance of ADC ?
>
> Bob
>

>>The ADC on an N210 has over 80dB of dynamic range.  If that >>isn't
enough, then your application can adjust the RF gain to taste.

>>Only a subset of applications actually benefit from the usual >>hardware
AGC schemes, and such schemes are invariably >>application-specific, so
there's
  >>no *automatic* gain control.  But your application can >>dynamically
make gain adjustments as it goes.


Hi Marcus thanks for response, If there is no automatic gain control then
how does it is ensured that ADC doesn't saturate ? I mean what if there is
a signal whose amplitude is greater that ADC's highest input level ?  Won't
it saturate the ADC ? Also what if the signal is too weak to span much of
the ADC input voltage, then again we are not using all bits effectively.
Guide please.

Thanks,

Bob

>>--
>>Marcus Leech
>>Principal Investigator
>>Shirleys Bay Radio Astronomy Consortium
>>http://www.sbrac.org
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] AGC and Dynamic Range of ADC

[bob wole]

Can somebody please guide me on this ?

Bob


On Fri, Sep 20, 2013 at 4:44 PM, bob wole  wrote:

> I have USRPN210 with WBX and RFX2400. Is there any AGC chip on N210
> motherboard or WBX, RFX2400 before ADC to utilize the dynamic range of ADC
> ? if yes, which one? If not, then won't the varying input signal (for
> example signal from moving object)  to ADC affect the performance of ADC ?
>
> Bob
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] AGC and Dynamic Range of ADC

[bob wole]

I have USRPN210 with WBX and RFX2400. Is there any AGC chip on N210
motherboard or WBX, RFX2400 before ADC to utilize the dynamic range of ADC
? if yes, which one? If not, then won't the varying input signal (for
example signal from moving object)  to ADC affect the performance of ADC ?

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