Re: [Discuss-gnuradio] how to get started with python in gnuradio

[Tom Rondeau]

On Sun, Jun 9, 2013 at 9:48 PM, vamshi krishna dodla
 wrote:
> Hi all
> It would be very helpful to me if some one tells me how to get started with
> python in gnu radio.I see an entire page dedicated to python programming but
> it does not say anything about getting started.Please don't say to use
> #!/usr/bin/env /python part in that page.Any link to how to get started with
> an example would be helpful.
>
> --
> Thanks & Regards
> Vamshi Krishna Dodla


When you have the source code, every top level component (e.g.,
gr-digital) has an 'examples' directory. Most of the examples are in
Python. Some components have examples in GRC, Python, and C++, in
which case you'll find the Python examples in 'examples/python'.

Tom

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

Re: [Discuss-gnuradio] out of tree module with code generation problem

[Tom Rondeau]

On Sat, Jun 8, 2013 at 1:49 PM, Achilleas Anastasopoulos
 wrote:
> I have an out of tree module and I want to create a block
> that is automatically expanded for different input/output types.
>
> I have changed all CMakeList.txt files according to
> gr-blocks directory.
>
> However "make" complaints it cannot find the buid_utils
> module in the generate_helper.py script.
>
> In the generate_helper.py script I notice that the
> ${GR_CORE_PYTHONPATH}
> variable is not set...
>
> I quick-fixed that by hardwiring the  correct path, but I was wondering
> if there is a more permanet fix for that.
>
> thanks,
> Achilleas

That seems like an unexplored idea. The build_utils modules is located
in gnuradio-runtime/python/, but it is not installed, so there would
be no way for the OOT component to find it.

I have created Issue #552 (http://gnuradio.org/redmine/issues/552) for this.

Can you look at what I suggest in there (adding build_utils.py to your
OOT python directory) and give me feedback?

Thanks,
Tom

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

Re: [Discuss-gnuradio] about gps lock

[Zan Li]

I have done more tests about the gps message.
while(1){
sleep(1);
std::cout << usrp->get_mboard_sensor("gps_gprmc",0).to_pp_string()
<< std::endl;
}

For the output, at the beginning, there are gps_gprmc message outputs but
after it runs for a while, there would be no gps_gprmc message output. If I
restart, it also works at the beginning. (I update the uhd to 003.005.003
and it works like that. For the old version (003.005.001) I did not meet
this problem.) Does somebody know why it is? thanks!

Best regards

Zan

2013/6/10 Zan Li 

> Hi Marcus,
> We have extend the antenna out to the windows and there is an adequate
> view of sky. When I use the uhd UHD_003.005.001, there is no such problem
> but now I upadate the version to UHD_003.005.003.
>
> Best regards
>
> Zan
>
>
> 2013/6/8 Marcus D. Leech 
>
> **
>>
>>Dear all,
>>  I meet a problem about the gpsdo for lock. First I check the
>> usrp->get_mboard_sensor("gps_locked",0); it indicates the gps is locked.
>> Then the program is sleep for 5 mins. Then I check the gps again but in
>> this time it does not lock. I do not think that in this 5 mins the gps lost
>> lock because every time I try like this, the first time it is locked but
>> after 5 mins it is unlocked, as follows:
>>
>>
>> *The reference clock is:GPS lock status: locked*
>> Setting device clock source to:external
>> Setting device clock rate to:1e+08
>> Setting time source to:external
>> *The reference clock is:GPS lock status: unlocked*
>>
>> UHD Warning:
>> get_time: ValueError: get_nmea(): no GPRMC message found
>>
>> UHD Warning:
>> get_time: ValueError: get_nmea(): no GPRMC message found
>>  *(Here I can not read the gps time from the gpsdo, I think it is
>> because the gpsdo does not lock).*
>>
>>  Does anybody meet the similar problem? Any suggestion would be
>> appreciated.
>>
>>  Best regards
>>
>>  Zan
>>
>>
>> ___
>> Discuss-gnuradio mailing 
>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>  So, I will ask an obvious question:
>>
>> Does your GPS receiver have an adequate view of the sky?  That is, does
>> it have an external, amplified antenna outdoors, or near a window that
>> doesn't
>>   have low-E film on it.
>>
>>
>>
>> --
>> Marcus Leech
>> Principal Investigator
>> Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org
>>
>>
>> ___
>> 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] Tun/Tap Problem while Running tunnel.py while wireshark recognizes

[Tom Rondeau]

On Thu, Jun 6, 2013 at 3:22 PM, Jay Prakash
 wrote:
> We are working on establishing a tunnel for MAC protocol design using
> tunnel.py given as example in GNU Radio but are unable to receive ping reply
> from the other node.
>
> We created tun/tap interface using ./tunnel.py -f 990M and ipconfig
> 192.168.200.1 on Machine A connected to N210 series of USRP.
> and ./tunnel.py -f 990M and ifconfig 192.168.200.2 on machine B.
>
> 1. Now on pinging machine B from A we can see ping packets being sent to B
> by A using wireshark, but there is no reply on node A.
>
> 2. We went into details and saw there were ARQ requests from B repetitively.
> I manually added the mac address to update the table.
> Now ARQ request ceased to exist but still there were no replies on A.
>
>
> 3. Since we knew the Packaging details of ICMP we read the packets being
> received by B and found the exact source address of A from the frame. It
> means message have been successfully decoded by the destination and it knows
> whom to reply for the ping but still I don't find any reception confirmation
> on source side.
>
> What may be the possible problems?USRP antenna gain?Packets collision?
>
> In short we are unable to use tunnely.py  and are seeking for possible
> causes.
>
> Jay Prakash
> Senior Undergraduate

You could be having gain issues. Test this using the standard
uhd_siggen and uhd_fft programs to understand what settings give you
the best gain.

Also, try using different frequencies for transmit and receive (use
the -h on the command line to figure out how to do this).

Tom

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

Re: [Discuss-gnuradio] How to save/read sc8 format to/from file and convert it to complex float 32?

[Tom Rondeau]

On Thu, Jun 6, 2013 at 11:46 AM, Michael Ossmann  wrote:
> On Thu, Jun 06, 2013 at 11:27:02AM -0400, Josh Blum wrote:
>>
>> A block that implements this conversion w/ a configurable scalar would
>> be ideal.
>
> That would be very nice.  I've been using (for input from sc8 file to a
> complex flowgraph):
>
> UChar to Float -> Deinterleave => Float to Complex
>
> Since my samples are unsigned chars, this gives me an offset of
> approximately 128 that I can correct with Add Const either before
> Deinterleave or after Float to Complex (where it is 128+128j).
>
> Unsigned sc8 is the primary data format used by HackRF, so this may be
> interesting to other HackRF users.  The conversion is handled by
> gr-osmosdr when communicating with a HackRF directly from GNU Radio, but
> files transmitted or received via the hackrf_transfer utility are in the
> unsigned sc8 format.
>
> Mike

Most of our conversion blocks use Volk now, which also accepts a
scalar as part of the conversion process. Very efficient. The
uchar_to_float block doesn't use Volk, probably because there's no
currently existing Volk kernel for it.

It should be an easy mod to add the right kernel (if it doesn't exist)
and then use it in the block. Should speed things up a lot.

Tom

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

Re: [Discuss-gnuradio] GnuRadio + EveryCircuit?

[Tom Rondeau]

On Wed, Jun 5, 2013 at 2:00 PM, Joel Mayer  wrote:
> Here is a link to an Android ap called: EveryCircuit
>
> http://www.everycircuit.com/
>
> My question is, if I learn how to design circuits
> on this application, will I gain insights into the
> subtleties of gnuradio?

Hedging here with a... maybe...

Don't know how this works underneath, but you probably won't get too
much from it as to how GNU Radio works. But what you might get is some
better understanding of the hardware issues involved in doing radio
comms. That's not directly related to GNU Radio, but it will
definitely help you work with radio signals through our software.

Tom

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

Re: [Discuss-gnuradio] Detecting underflows with uhd_usrp_sink

[Sean Nowlan]

Do late packets always get dropped by the USRP? What happens if its buffers get 
filled up with samples, all of which are late?

"Marcus D. Leech"  wrote:

>> L = late packet, there was a time on the packet which was>  time on
>> device when
>>
>>
>There are two different "cases" for late packets happening.
>
>The first is that you haven't sent your packet far enough in advance to 
>account for latency variations on the host.  Unfortunately, on a 
>general-purpose
>   OS like Windows or Linux, latency variability can be extreme, and for 
>long-running flow-graphs you might need to develop a good model to determine
>   what the worst-case is and account for that.
>
>The second is that the clock on the USRP and the clock on the host will 
>tend to drift apart over time, particularly if both of them are "free 
>running".
>   So when you schedule timed bursts far enough in advance during the 
>start of a "session", it's entirely possible that after quite some time, the
>   two clocks have drifted apart unfavourably in terms of allowing you 
>to schedule things far enough in advance, relative to the USRP clock.
>   PC clocks are *terrible* by themselves.  They'll drift significant 
>fractions of a second on a daily basis without any outside steering. 
>  The USRP
>   clock, even free-running, is typically much, much better.
>
>
>-- 
>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
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Detecting underflows with uhd_usrp_sink

[Marcus Leech]

I believe that they are all dropped, but Josh can comment more definitively.
 
on Jun 10, 2013, Sean Nowlan  wrote:
Do late packets always get dropped by the USRP? What happens if its buffers get filled up with samples, all of which are late?"Marcus D. Leech"  wrote:>> L = late packet, there was a time on the packet which was> time on>> device when>There are two different "cases" for late packets happening.>>The first is that you haven't sent your packet far enough in advance to >account for latency variations on the host. Unfortunately, on a >general-purpose> OS like Windows or Linux, latency variability can be extreme, and for >long-running flow-graphs you might need to develop a good model to determine> what the worst-case is and account for that.>>The second is that the clock on the USRP and the clock on the host will >tend to drift apart over time, particularly if both of them are "free >running".> So when you schedule timed bursts far enough in advance during the >start of a "session", it's entirely possible that after quite some time, the> two clocks have drifted apart unfavourably in terms of allowing you >to schedule things far enough in advance, relative to the USRP clock.> PC clocks are *terrible* by themselves. They'll drift significant >fractions of a second on a daily basis without any outside steering. > The USRP> clock, even free-running, is typically much, much better.>>>-- >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


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

Re: [Discuss-gnuradio] Detecting underflows with uhd_usrp_sink

[Adeel Anwar]

See this post in context
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2012-September/005352.html


On Mon, Jun 10, 2013 at 7:13 AM, Marcus Leech  wrote:

> I believe that they are all dropped, but Josh can comment more
> definitively.
>
>
> on Jun 10, 2013, *Sean Nowlan*  wrote:
>
> Do late packets always get dropped by the USRP? What happens if its
> buffers get filled up with samples, all of which are late?
>
> "Marcus D. Leech"  wrote:
>
> >> L = late packet, there was a time on the packet which was> time on
> >> device when
> >>
> >>
> >There are two different "cases" for late packets happening.
> >
> >The first is that you haven't sent your packet far enough in advance to
> >account for latency variations on the host. Unfortunately, on a
> >general-purpose
> > OS like Windows or Linux, latency variability can be extreme, and for
> >long-running flow-graphs you might need to develop a good model to
> determine
> > what the worst-case is and account for that.
> >
> >The second is that the clock on the USRP and the clock on the host will
> >tend to drift apart over time, particularly if both of them are "free
> >running".
> > So when you schedule timed bursts far enough in advance during the
> >start of a "session", it's entirely possible that after quite some time,
> the
> > two clocks have drifted apart unfavourably in terms of allowing you
> >to schedule things far enough in advance, relative to the USRP clock.
> > PC clocks are *terrible* by themselves. They'll drift significant
> >fractions of a second on a daily basis without any outside steering.
> > The USRP
> > clock, even free-running, is typically much, much better.
> >
> >
> >--
> >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
>
>
> ___
> 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] Tun/Tap Problem while Running tunnel.py while wireshark recognizes

[Jay Prakash]

Yes I have tested using different frequency.No help.

And while debugging I figured out that PHY layer receives the packet from
transmitter sent as ping ICMP packets and decodes the sender's address.
After that it writes to the tun/tap. But tun/tap reply is unavailable.
Ie there is some problem in tun/tap and PHY layer interface.

How to figure this out?


Jay Prakash
Senior Undergraduate
Electronics Engineering
IIT (BHU)
VARANASI

+91-9559475258
http://about.me/jay.prakash/
http://www.linkedin.com/profile/view?id=91120191&trk=hb_tab_pro_top




On Mon, Jun 10, 2013 at 7:13 PM, Tom Rondeau  wrote:

> On Thu, Jun 6, 2013 at 3:22 PM, Jay Prakash
>  wrote:
> > We are working on establishing a tunnel for MAC protocol design using
> > tunnel.py given as example in GNU Radio but are unable to receive ping
> reply
> > from the other node.
> >
> > We created tun/tap interface using ./tunnel.py -f 990M and ipconfig
> > 192.168.200.1 on Machine A connected to N210 series of USRP.
> > and ./tunnel.py -f 990M and ifconfig 192.168.200.2 on machine B.
> >
> > 1. Now on pinging machine B from A we can see ping packets being sent to
> B
> > by A using wireshark, but there is no reply on node A.
> >
> > 2. We went into details and saw there were ARQ requests from B
> repetitively.
> > I manually added the mac address to update the table.
> > Now ARQ request ceased to exist but still there were no replies on A.
> >
> >
> > 3. Since we knew the Packaging details of ICMP we read the packets being
> > received by B and found the exact source address of A from the frame. It
> > means message have been successfully decoded by the destination and it
> knows
> > whom to reply for the ping but still I don't find any reception
> confirmation
> > on source side.
> >
> > What may be the possible problems?USRP antenna gain?Packets collision?
> >
> > In short we are unable to use tunnely.py  and are seeking for possible
> > causes.
> >
> > Jay Prakash
> > Senior Undergraduate
>
> You could be having gain issues. Test this using the standard
> uhd_siggen and uhd_fft programs to understand what settings give you
> the best gain.
>
> Also, try using different frequencies for transmit and receive (use
> the -h on the command line to figure out how to do this).
>
> Tom
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] gnuradio-companion

[Pratik Kumar]

I am new to gnuradio.
Can i get this channel as a block in gnuradio-companion.

http://gnuradio.org/redmine/projects/gnuradio/repository/revisions/d5168150815339f0d3b117bcfb4d2c4265d15b33/diff/gnuradio-core/src/python/gnuradio/blks2impl/channel_model.py
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gnuradio-companion

[Tom Rondeau]

On Mon, Jun 10, 2013 at 11:50 AM, Pratik Kumar
 wrote:
> I am new to gnuradio.
> Can i get this channel as a block in gnuradio-companion.

Depends on what version you are using, but most likely, yes.

In the "Blocks" list on the right hand side of gnuradio-companion you
can find this under "Channel Models" (or just search for channel model
by typing in your search query after clicking into the box of blocks).

We have moved that block out of Python and reimplemented it in C++, so
you can't get exactly the block you linked to, but the C++ block
functions the same.

Tom

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

Re: [Discuss-gnuradio] gnuradio-companion

[Marcus Leech]

Assuming you're using a recent version of GRC, just start typing in the blocks window which enables a search.  So typing "channel model" here will take you to the channel model.
 
on Jun 10, 2013, Pratik Kumar  wrote:

I am new to gnuradio.
Can i get this channel as a block in gnuradio-companion.
 
http://gnuradio.org/redmine/projects/gnuradio/repository/revisions/d5168150815339f0d3b117bcfb4d2c4265d15b33/diff/gnuradio-core/src/python/gnuradio/blks2impl/channel_model.py
 
 
 

___Discuss-gnuradio mailing listDiscuss-gnuradio@gnu.orghttps://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] Detecting underflows with uhd_usrp_sink

[Josh Blum]

On 06/10/2013 09:43 AM, Sean Nowlan wrote:
> Do late packets always get dropped by the USRP? What happens if its buffers 
> get filled up with samples, all of which are late?

The stream args have a policy parameter. Also, these args can be set
from a parameter in the USRP GRC blocks, as well as the constructor for
the gr-uhd blocks themselves.

This should be helpful:
http://files.ettus.com/uhd_docs/doxygen/html/structuhd_1_1stream__args__t.html#a4463f2eec2cc7ee70f84baacbb26e1ef

-josh

> 
> "Marcus D. Leech"  wrote:
> 
>>> L = late packet, there was a time on the packet which was>  time on
>>> device when
>>>
>>>
>> There are two different "cases" for late packets happening.
>>
>> The first is that you haven't sent your packet far enough in advance to 
>> account for latency variations on the host.  Unfortunately, on a 
>> general-purpose
>>   OS like Windows or Linux, latency variability can be extreme, and for 
>> long-running flow-graphs you might need to develop a good model to determine
>>   what the worst-case is and account for that.
>>
>> The second is that the clock on the USRP and the clock on the host will 
>> tend to drift apart over time, particularly if both of them are "free 
>> running".
>>   So when you schedule timed bursts far enough in advance during the 
>> start of a "session", it's entirely possible that after quite some time, the
>>   two clocks have drifted apart unfavourably in terms of allowing you 
>> to schedule things far enough in advance, relative to the USRP clock.
>>   PC clocks are *terrible* by themselves.  They'll drift significant 
>> fractions of a second on a daily basis without any outside steering. 
>>  The USRP
>>   clock, even free-running, is typically much, much better.
>>
>>
>> -- 
>> 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
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 

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

[Discuss-gnuradio] Regarding exponential operator in gnuradio

[vamshi krishna dodla]

Hi all, does gnuradio have an exponential operator (like e^jw). If not how
to implement it in gnuradio.


-- 
Thanks & Regards
Vamshi Krishna Dodla
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Detecting underflows with uhd_usrp_sink

[Sean Nowlan]

On 06/10/2013 01:17 PM, Josh Blum wrote:


On 06/10/2013 09:43 AM, Sean Nowlan wrote:

Do late packets always get dropped by the USRP? What happens if its buffers get 
filled up with samples, all of which are late?

The stream args have a policy parameter. Also, these args can be set
from a parameter in the USRP GRC blocks, as well as the constructor for
the gr-uhd blocks themselves.

This should be helpful:
http://files.ettus.com/uhd_docs/doxygen/html/structuhd_1_1stream__args__t.html#a4463f2eec2cc7ee70f84baacbb26e1ef


Ok, makes sense. So lets say I scheduled 20 minutes of bursts (1 second 
period with 50/50 duty cycle) and I started the flowgraph 10 minutes 
late. With the "next_burst" policy, could I rely on the USRP to 
dutifully drop all late bursts? Are the packets dropped in the Ethernet 
buffer or does the TX sample buffer fill up first? If it's the latter 
case, my scenario implies that the TX buffer will have to be filled and 
emptied multiple times until there are no more late packets, and normal 
transmissions begin. This would happen at the sample rate times the 
number of samples sent.


I suppose I'd also want to implement a message handler to drop the flood 
of "L" symbols before they get piped to STDERR/STDOUT.


Do I have the right understanding of this process? Thanks!

--sean

P.S. -- Copying to USRP list since this could be relevant to people there.


-josh


"Marcus D. Leech"  wrote:


L = late packet, there was a time on the packet which was>  time on
device when



There are two different "cases" for late packets happening.

The first is that you haven't sent your packet far enough in advance to
account for latency variations on the host.  Unfortunately, on a
general-purpose
   OS like Windows or Linux, latency variability can be extreme, and for
long-running flow-graphs you might need to develop a good model to determine
   what the worst-case is and account for that.

The second is that the clock on the USRP and the clock on the host will
tend to drift apart over time, particularly if both of them are "free
running".
   So when you schedule timed bursts far enough in advance during the
start of a "session", it's entirely possible that after quite some time, the
   two clocks have drifted apart unfavourably in terms of allowing you
to schedule things far enough in advance, relative to the USRP clock.
   PC clocks are *terrible* by themselves.  They'll drift significant
fractions of a second on a daily basis without any outside steering.
  The USRP
   clock, even free-running, is typically much, much better.


--
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

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


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



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

Re: [Discuss-gnuradio] Regarding exponential operator in gnuradio

[Marcus Leech]

I think there's a generic "transcendental" block that actually allows you to call anything in libm.   It may be slow.
 
on Jun 10, 2013, vamshi krishna dodla  wrote:

Hi all, does gnuradio have an exponential operator (like e^jw). If not how to implement it in gnuradio. 

-- 
Thanks & Regards
Vamshi Krishna Dodla




___Discuss-gnuradio mailing listDiscuss-gnuradio@gnu.orghttps://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] Detecting underflows with uhd_usrp_sink

[Josh Blum]

> 
> Ok, makes sense. So lets say I scheduled 20 minutes of bursts (1 second
> period with 50/50 duty cycle) and I started the flowgraph 10 minutes
> late. With the "next_burst" policy, could I rely on the USRP to
> dutifully drop all late bursts? Are the packets dropped in the Ethernet
> buffer or does the TX sample buffer fill up first? If it's the latter


The bursts will be dropped as they are consumed by the VITA deframer.
This deframer sits between the TX buffering and the transmit DSP. So
yes, there will be some amount of buffered samples in the device, which
will need to be dropped.

Anything that is due for transmission that is several orders of
magnitude >> ethernet latency should probably stay in the host
application. :-)

> case, my scenario implies that the TX buffer will have to be filled and
> emptied multiple times until there are no more late packets, and normal
> transmissions begin. This would happen at the sample rate times the
> number of samples sent.
> 

Because the DSP is upstream of the framer. The framer can drain samples
out of the buffering at the rate of the FPGA clock, this is ~100Msps for
the N210.

-josh

> I suppose I'd also want to implement a message handler to drop the flood
> of "L" symbols before they get piped to STDERR/STDOUT.
> 
> Do I have the right understanding of this process? Thanks!
> 
> --sean
> 
> P.S. -- Copying to USRP list since this could be relevant to people there.
> 
>> -josh
>>
>>> "Marcus D. Leech"  wrote:
>>>
> L = late packet, there was a time on the packet which was>  time on
> device when
>
>
 There are two different "cases" for late packets happening.

 The first is that you haven't sent your packet far enough in advance to
 account for latency variations on the host.  Unfortunately, on a
 general-purpose
OS like Windows or Linux, latency variability can be extreme, and
 for
 long-running flow-graphs you might need to develop a good model to
 determine
what the worst-case is and account for that.

 The second is that the clock on the USRP and the clock on the host will
 tend to drift apart over time, particularly if both of them are "free
 running".
So when you schedule timed bursts far enough in advance during the
 start of a "session", it's entirely possible that after quite some
 time, the
two clocks have drifted apart unfavourably in terms of allowing you
 to schedule things far enough in advance, relative to the USRP clock.
PC clocks are *terrible* by themselves.  They'll drift significant
 fractions of a second on a daily basis without any outside steering.
   The USRP
clock, even free-running, is typically much, much better.


 -- 
 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
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> ___
> Discuss-gnuradio 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] gnuradio software architecture

[Yogesh Dahiya]

Thanks for the link. I got the idea of gnuradio scheduler.
top_block calls start which creates gnuradio_scheduler which topological
sort the flowgraph and create threads for each block according to sort.
But it did'nt explain how blocks are connected .I know that publish and
subscribe are used to connect blocks but how stream is buffered and
processed inside block is vague to me. Do you have Zhuo Lu paper explaining
how gnuradio core works. Sumit's link is not working.
If you have any more resource do forward.
Thanks again


On Mon, Jun 10, 2013 at 12:10 PM, Ankit Kaushik <
kaus...@int.uni-karlsruhe.de> wrote:

>  **
> On 10.06.2013 05:34, Yogesh Dahiya wrote:
> **
>
> **Hey is there any documentation explaining the software architecture of
> gnuradio. I means how blocks are connected , scheduled. Basically how
> everything is working behind the scene**
>
> Last year Sumit tried to explain this in his blog...
>
>
> http://sumitgnuradio.blogspot.de/2012/10/gnuradio-scheduler-part-1-how-gnu-radio.html?view=timeslide
>
> might be helpful!
>
> Ankit
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] USRP_N200 unable to connect via vmplayer

[Ankan Roybardhan]

I have vmplayer virtual machine running on my computer as my system is GPT
partition style and which is not taking dual boot of any release of ubuntu.

I connect to an ethernet port to a USRP rx... and do a uhd_find_devices ..
it says no device found.. although I have a valid gnuradio distro +uhd on
my computer and it works fine when I am not using the USRP though..

Could it be because of the vm that I am using? Please suggest what do I
need to do!!

this is my eth0 config-

eth0  Link encap:Ethernet  HWaddr 00:0c:29:23:94:4e
  inet addr:192.168.10.1  Bcast:192.168.10.255  Mask:255.255.255.0
  inet6 addr: fe80::20c:29ff:fe23:944e/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:39419 errors:0 dropped:0 overruns:0 frame:0
  TX packets:14888 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:48827305 (48.8 MB)  TX bytes:1521561 (1.5 MB)
  Interrupt:19 Base address:0x2000


This shows up when I am doing my firmware update-


ankan@ubuntu:~/Downloads/uhd-images_003.005.001-release/share/uhd/images$
usrp_n2xx_simple_net_burner  --addr 192.168.10.3 --fw usrp_n200_fw.bin
--fpga usrp_n200_r3_fpga.bin --auto_reboot
linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.005.003-78-g49a4929b

Searching for USRP N2XX with IP address 192.168.10.3.
Error: No USRP N2XX found.

my machine is 192.168.10.1 .. the usrp is on 192.168.10.3 via same ethernet
sw



-Regards,
Ankan Roybardhan
University of Florida.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] reg. PSK Mod Block in Gnu radio

[vamshi krishna dodla]

http://gnuradio.squarespace.com/storage/tutorial/rondeau-costterra2.pdf


Hi all, why does the output of PSK Mod block is imperfect, compared to
theoritical QPSK constellation.( iam implementing qpsk with 4 sampl/sym and
4 constellation points).The experiment im doing is the same in link (
http://gnuradio.squarespace.com/storage/tutorial/rondeau-costterra2.pdf).


-- 
Thanks & Regards
Vamshi Krishna.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] reg. PSK Mod Block in Gnu radio

[Marcus D. Leech]

On 06/10/2013 07:25 PM, vamshi krishna dodla wrote:

http://gnuradio.squarespace.com/storage/tutorial/rondeau-costterra2.pdf


Hi all, why does the output of PSK Mod block is imperfect, compared to 
theoritical QPSK constellation.( iam implementing qpsk with 4 
sampl/sym and 4 constellation points).The experiment im doing is the 
same in link 
(http://gnuradio.squarespace.com/storage/tutorial/rondeau-costterra2.pdf).



--
Thanks & Regards
Vamshi Krishna.


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
This kind of question is *much* better accompanied by the flow-graph 
you're working, perhaps an FFT and constellation plot, etc, etc.


You question, as presented, reduces to "why does thing thing I'm doing 
not work".  Which nobody will be able to help you with.




--
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] USRP_N200 unable to connect via vmplayer

[Clark Pope]

> Date: Mon, 10 Jun 2013 18:00:21 -0400 
> From: ankan...@gmail.com 
> To: discuss-gnuradio@gnu.org 
> Subject: [Discuss-gnuradio] USRP_N200 unable to connect via vmplayer 
> 
> I have vmplayer virtual machine running on my computer as my system is 
> GPT partition style and which is not taking dual boot of any release of 
> ubuntu. 
> 
> I connect to an ethernet port to a USRP rx... and do a uhd_find_devices 
> .. it says no device found.. although I have a valid gnuradio distro 
> +uhd on my computer and it works fine when I am not using the USRP 
> though.. 
> 
> Could it be because of the vm that I am using? Please suggest what do I 
> need to do!! 
> 
> this is my eth0 config- 
> 
> eth0 Link encap:Ethernet HWaddr 00:0c:29:23:94:4e 
> inet addr:192.168.10.1 Bcast:192.168.10.255 Mask:255.255.255.0 
> inet6 addr: fe80::20c:29ff:fe23:944e/64 Scope:Link 
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 
> RX packets:39419 errors:0 dropped:0 overruns:0 frame:0 
> TX packets:14888 errors:0 dropped:0 overruns:0 carrier:0 
> collisions:0 txqueuelen:1000 
> RX bytes:48827305 (48.8 MB) TX bytes:1521561 (1.5 MB) 
> Interrupt:19 Base address:0x2000 
> 
> 
> This shows up when I am doing my firmware update- 
> 
> 
> ankan@ubuntu:~/Downloads/uhd-images_003.005.001-release/share/uhd/images$ 
> usrp_n2xx_simple_net_burner --addr 192.168.10.3 --fw usrp_n200_fw.bin 
> --fpga usrp_n200_r3_fpga.bin --auto_reboot 
> linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.005.003-78-g49a4929b 
> 
> Searching for USRP N2XX with IP address 192.168.10.3. 
> Error: No USRP N2XX found. 
> 
> my machine is 192.168.10.1 .. the usrp is on 192.168.10.3 via same 
> ethernet sw 
> 
> 
> 
> -Regards, 
> Ankan Roybardhan 
> University of Florida. 
> 

You're sure its not at the default address 192.168.10.2?

Don't know if you have the same problem but I use a USB to GigE adapter from 
vmware player and I found that it ONLY works if I boot the VM with the 
interface that is connected to the USRP as the only active network connection. 
I can enable the network interface to the host OS after I boot and it still 
works but for some reason if the VMnetX interfaces are active at boot it messes 
up the ability to find the USRP. 

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

Re: [Discuss-gnuradio] reg. PSK Mod Block in Gnu radio

[Marcus D. Leech]

On 06/10/2013 08:13 PM, vamshi krishna dodla wrote:

can you please reply



When I'm good and ready.


--
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] make test errors

[Dave L]

The CPU on the laptop is an Intel i3-2350M (64 bit).

What steps should I take (or where can I learn how) to resolve the problem with 
Volk?

Dave





 From: Tom Rondeau 
To: Botany Dave  
Sent: Monday, June 10, 2013 6:41 AM
Subject: Re: [Discuss-gnuradio] make test errors
 

On Thu, Jun 6, 2013 at 11:52 PM, Botany Dave  wrote:
> I'm new to this, and I'm sure it will show...
>
> I am trying to install and run Gnu Radio in an Ubuntu 12.10 environment. I
> followed the instructions at
> http://gnuradio.org/redmine/projects/gnuradio/wiki/UbuntuInstall#Installation-Overview
> and am getting errors on four modules when I run make test. They are:
>
> 86 - qa_fir_filter
> 91 - qa_freq__xlating_fir_filter
> 150 - qa_constellation_receiver
> 169 - qa_codec2_vocoder
>
> Here is the output of ctest -V -R qa for each of those modules. I'd really
> appreciate any guidance on how to resolve these failures.
>
> 86: Test command: /bin/sh
> "/home/dave/gnuradio/build/gr-filter/python/qa_fir_filter_test.sh"
> 86: Test timeout computed to be: 9.99988e+06
> 86: .FF
> 86: ==
> 86: FAIL: test_fir_filter_scc_001 (__main__.test_filter)
> 86: --
> 86: Traceback (most recent call last):
> 86:   File "/home/dave/gnuradio/gr-filter/python/qa_fir_filter.py", line
> 262, in test_fir_filter_scc_001
> 86:     self.assertComplexTuplesAlmostEqual(expected_data, result_data, 5)
> 86:   File
> "/home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py", line
> 74, in assertComplexTuplesAlmostEqual
> 86:     self.assertComplexAlmostEqual (a[i], b[i], places, msg)
> 86:   File
> "/home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py", line
> 47, in assertComplexAlmostEqual
> 86:     (msg or '%s != %s within %s places' % (`first`, `second`, `places`
> ))
> 86: AssertionError: (0.5+1j) != (nan+nanj) within 5 places
> 86:
> 86: ==
> 86: FAIL: test_fir_filter_scc_002 (__main__.test_filter)
> 86: --
> 86: Traceback (most recent call last):
> 86: Using Volk machine: avx_32_mmx
> 86:   File "/home/dave/gnuradio/gr-filter/python/qa_fir_filter.py", line
> 281, in test_fir_filter_scc_002
> 86:     self.assertComplexTuplesAlmostEqual(expected_data, result_data, 5)
> 86:   File
> "/home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py", line
> 74, in assertComplexTuplesAlmostEqual
> 86:     self.assertComplexAlmostEqual (a[i], b[i], places, msg)
> 86:   File
> "/home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py", line
> 47, in assertComplexAlmostEqual
> 86:     (msg or '%s != %s within %s places' % (`first`, `second`, `places`
> ))
> 86: AssertionError: (0.5+1j) != (nan+nanj) within 5 places
> 86:
> 86: --
> 86: Ran 11 tests in 0.035s
> 86:
> 86: FAILED (failures=2)
> 1/1 Test #86: qa_fir_filter ***Failed    0.30 sec
>
> 0% tests passed, 1 tests failed out of 1
>
> Total Test time (real) =   0.31 sec
>
> The following tests FAILED:
>      86 - qa_fir_filter (Failed)
> Errors while running CTest
>
>
> 91: Test command: /bin/sh
> "/home/dave/gnuradio/build/gr-filter/python/qa_freq_xlating_fir_filter_test.sh"
> 91: Test timeout computed to be: 9.99988e+06
> 91: 
> 91: ==
> 91: FAIL: test_fir_filter_scc_001 (__main__.test_freq_xlating_filter)
> 91: --
> 91: Traceback (most recent call last):
> 91:   File
> "/home/dave/gnuradio/gr-filter/python/qa_freq_xlating_fir_filter.py", line
> 412, in test_fir_filter_scc_001
> 91:     self.assertComplexTuplesAlmostEqual(expected_data,
> result_data[-20:], 5)
> 91:   File
> "/home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py", line
> 74, in assertComplexTuplesAlmostEqual
> 91:     self.assertComplexAlmostEqual (a[i], b[i], places, msg)
> 91:   File
> "/home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py", line
> 47, in assertComplexAlmostEqual
> 91:     (msg or '%s != %s within %s places' % (`first`, `second`, `places`
> ))
> 91: AssertionError: (-0.00775564694777+0.0437113791704j) != (nan+nanj)
> within 5 places
> 91:
> 91: ==
> 91: Using Volk machine: avx_32_mmx
> 91: FAIL: test_fir_filter_scc_002 (__main__.test_freq_xlating_filter)
> 91: --
> 91: Traceback (most recent call last):
> 91:   File
> "/home/dave/gnuradio/gr-filter/python/qa_freq_xlating_fir_filter.py", line
> 442, in test_fir_filter_scc_002
> 91:     self.assertComplexTuplesAlmostEqual(expected_data,

Re: [Discuss-gnuradio] make test errors

[Josh Blum]

Run volk/lib/test_all from the build dir

If a kernel fails, it will tell you which one, start commenting out its
implementations in the source dir volk/kernels/volk/volk_*.h until the
test works. We narrow down suspect implementation and fix.

-josh

On 06/10/2013 09:57 PM, Dave L wrote:
> The CPU on the laptop is an Intel i3-2350M (64 bit).
> 
> What steps should I take (or where can I learn how) to resolve the problem 
> with Volk?
> 
> Dave
> 
> 
> 
> 
> 
>  From: Tom Rondeau 
> To: Botany Dave  
> Sent: Monday, June 10, 2013 6:41 AM
> Subject: Re: [Discuss-gnuradio] make test errors
>  
> 
> On Thu, Jun 6, 2013 at 11:52 PM, Botany Dave  wrote:
>> I'm new to this, and I'm sure it will show...
>>
>> I am trying to install and run Gnu Radio in an Ubuntu 12.10 environment. I
>> followed the instructions at
>> http://gnuradio.org/redmine/projects/gnuradio/wiki/UbuntuInstall#Installation-Overview
>> and am getting errors on four modules when I run make test. They are:
>>
>> 86 - qa_fir_filter
>> 91 - qa_freq__xlating_fir_filter
>> 150 - qa_constellation_receiver
>> 169 - qa_codec2_vocoder
>>
>> Here is the output of ctest -V -R qa for each of those modules. I'd really
>> appreciate any guidance on how to resolve these failures.
>>
>> 86: Test command: /bin/sh
>> "/home/dave/gnuradio/build/gr-filter/python/qa_fir_filter_test.sh"
>> 86: Test timeout computed to be: 9.99988e+06
>> 86: .FF
>> 86: ==
>> 86: FAIL: test_fir_filter_scc_001 (__main__.test_filter)
>> 86: --
>> 86: Traceback (most recent call last):
>> 86:   File "/home/dave/gnuradio/gr-filter/python/qa_fir_filter.py", line
>> 262, in test_fir_filter_scc_001
>> 86: self.assertComplexTuplesAlmostEqual(expected_data, result_data, 5)
>> 86:   File
>> "/home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py", line
>> 74, in assertComplexTuplesAlmostEqual
>> 86: self.assertComplexAlmostEqual (a[i], b[i], places, msg)
>> 86:   File
>> "/home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py", line
>> 47, in assertComplexAlmostEqual
>> 86: (msg or '%s != %s within %s places' % (`first`, `second`, `places`
>> ))
>> 86: AssertionError: (0.5+1j) != (nan+nanj) within 5 places
>> 86:
>> 86: ==
>> 86: FAIL: test_fir_filter_scc_002 (__main__.test_filter)
>> 86: --
>> 86: Traceback (most recent call last):
>> 86: Using Volk machine: avx_32_mmx
>> 86:   File "/home/dave/gnuradio/gr-filter/python/qa_fir_filter.py", line
>> 281, in test_fir_filter_scc_002
>> 86: self.assertComplexTuplesAlmostEqual(expected_data, result_data, 5)
>> 86:   File
>> "/home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py", line
>> 74, in assertComplexTuplesAlmostEqual
>> 86: self.assertComplexAlmostEqual (a[i], b[i], places, msg)
>> 86:   File
>> "/home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py", line
>> 47, in assertComplexAlmostEqual
>> 86: (msg or '%s != %s within %s places' % (`first`, `second`, `places`
>> ))
>> 86: AssertionError: (0.5+1j) != (nan+nanj) within 5 places
>> 86:
>> 86: --
>> 86: Ran 11 tests in 0.035s
>> 86:
>> 86: FAILED (failures=2)
>> 1/1 Test #86: qa_fir_filter ***Failed0.30 sec
>>
>> 0% tests passed, 1 tests failed out of 1
>>
>> Total Test time (real) =   0.31 sec
>>
>> The following tests FAILED:
>>   86 - qa_fir_filter (Failed)
>> Errors while running CTest
>>
>>
>> 91: Test command: /bin/sh
>> "/home/dave/gnuradio/build/gr-filter/python/qa_freq_xlating_fir_filter_test.sh"
>> 91: Test timeout computed to be: 9.99988e+06
>> 91: 
>> 91: ==
>> 91: FAIL: test_fir_filter_scc_001 (__main__.test_freq_xlating_filter)
>> 91: --
>> 91: Traceback (most recent call last):
>> 91:   File
>> "/home/dave/gnuradio/gr-filter/python/qa_freq_xlating_fir_filter.py", line
>> 412, in test_fir_filter_scc_001
>> 91: self.assertComplexTuplesAlmostEqual(expected_data,
>> result_data[-20:], 5)
>> 91:   File
>> "/home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py", line
>> 74, in assertComplexTuplesAlmostEqual
>> 91: self.assertComplexAlmostEqual (a[i], b[i], places, msg)
>> 91:   File
>> "/home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py", line
>> 47, in assertComplexAlmostEqual
>> 91: (msg or '%s != %s within %s places' % (`first`, `second`, `places`
>> ))
>> 91: AssertionError: (-0.00775564694777+0.0437113791704j) != (nan+nanj)
>> within 5 places
>> 91:
>> 91: ===

Re: [Discuss-gnuradio] Regarding exponential operator in gnuradio

[Nathan West]

http://gnuradio.org/doc/doxygen/gr__expj_8h_source.html

On Monday, June 10, 2013, vamshi krishna dodla wrote:

> Hi all, does gnuradio have an exponential operator (like e^jw). If not how
> to implement it in gnuradio.
>
>
> --
> Thanks & Regards
> Vamshi Krishna Dodla
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] pre-cog source doubt

[Yogesh Dahiya]

I was looking at the source of pre-cog and there is this piece of code
which i am not able to locate ( pmt_mgr() ) in the documentation.

self.mgr = pmt.pmt_mgr()
for i in range(64):
self.mgr.set(pmt.pmt_make_blob(1))
blob = self.mgr.acquire(True )


There is no reference of pmt_mgr in documentation. Can somebody
expalain its operation or point to relevant docs.

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

Re: [Discuss-gnuradio] pre-cog source doubt

[Yogesh Dahiya]

Okay I found in older grextras (
https://github.com/ncorgan/grextras/blob/master/include/gruel/pmt_mgr.h)

/*
 * 
 *  Manage a collection of PMTs -> memory wise
 *
 * When a PMT reference count becomes zero, the pmt and contents is deleted.
 * With a manager, the PMT will not be deleted, but released to the manager.
 * Then, the PMT can be acquired again for re-use by the user.
 *
 * This offers 2 benefits:
 *  - Avoids expensive memory allocation overhead (re-use is key)
 *  - An upstream producer can block until resources become released
 * 
 */



On Tue, Jun 11, 2013 at 10:13 AM, Yogesh Dahiya wrote:

>
> I was looking at the source of pre-cog and there is this piece of code which 
> i am not able to locate ( pmt_mgr() ) in the documentation.
>
> self.mgr = pmt.pmt_mgr()
> for i in range(64):
>   self.mgr.set(pmt.pmt_make_blob(1))
> blob = self.mgr.acquire(True )
>
>
> There is no reference of pmt_mgr in documentation. Can somebody expalain its 
> operation or point to relevant docs.
>
> Thanks
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Tun/Tap Problem while Running tunnel.py while wireshark recognizes

[Karan Talasila]

Hi Jay and Tom,
we too are having similar issues in communicating
between two USRP's using tunnel.py. we fiddled a lot with the gain values,
changed frequencies, modified delay variables in the code but found that
even though there is pretty good full duplex communication of packets
between the USRP's, the ping command is not giving a  good output. we tried
and received a minimum ping packet loss of 60%. we couldn't get better than
that with all the modifications we tried. we thought that the ping is not
receiving the icmp back in time so it is showing as a false packet because
the usrp packets reception on both ends is fine.

Any suggestions will be very helpful. Thank You.


On Mon, Jun 10, 2013 at 8:00 PM, Jay Prakash
wrote:

> Yes I have tested using different frequency.No help.
>
> And while debugging I figured out that PHY layer receives the packet from
> transmitter sent as ping ICMP packets and decodes the sender's address.
> After that it writes to the tun/tap. But tun/tap reply is unavailable.
> Ie there is some problem in tun/tap and PHY layer interface.
>
> How to figure this out?
>
>
> Jay Prakash
> Senior Undergraduate
> Electronics Engineering
> IIT (BHU)
> VARANASI
>
> +91-9559475258
> http://about.me/jay.prakash/
> http://www.linkedin.com/profile/view?id=91120191&trk=hb_tab_pro_top
>
>
>
>
> On Mon, Jun 10, 2013 at 7:13 PM, Tom Rondeau  wrote:
>
>> On Thu, Jun 6, 2013 at 3:22 PM, Jay Prakash
>>  wrote:
>> > We are working on establishing a tunnel for MAC protocol design using
>> > tunnel.py given as example in GNU Radio but are unable to receive ping
>> reply
>> > from the other node.
>> >
>> > We created tun/tap interface using ./tunnel.py -f 990M and ipconfig
>> > 192.168.200.1 on Machine A connected to N210 series of USRP.
>> > and ./tunnel.py -f 990M and ifconfig 192.168.200.2 on machine B.
>> >
>> > 1. Now on pinging machine B from A we can see ping packets being sent
>> to B
>> > by A using wireshark, but there is no reply on node A.
>> >
>> > 2. We went into details and saw there were ARQ requests from B
>> repetitively.
>> > I manually added the mac address to update the table.
>> > Now ARQ request ceased to exist but still there were no replies on A.
>> >
>> >
>> > 3. Since we knew the Packaging details of ICMP we read the packets being
>> > received by B and found the exact source address of A from the frame. It
>> > means message have been successfully decoded by the destination and it
>> knows
>> > whom to reply for the ping but still I don't find any reception
>> confirmation
>> > on source side.
>> >
>> > What may be the possible problems?USRP antenna gain?Packets collision?
>> >
>> > In short we are unable to use tunnely.py  and are seeking for possible
>> > causes.
>> >
>> > Jay Prakash
>> > Senior Undergraduate
>>
>> You could be having gain issues. Test this using the standard
>> uhd_siggen and uhd_fft programs to understand what settings give you
>> the best gain.
>>
>> Also, try using different frequencies for transmit and receive (use
>> the -h on the command line to figure out how to do this).
>>
>> Tom
>>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


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

Re: [Discuss-gnuradio] USRP_N200 unable to connect via vmplayer

[Karan Talasila]

Hi,
Check if your usrp is surely on 192.168.10.3. Run uhd_usrp_probe and
check if it is giving any output. Do you have gigabit ethernet card on your
laptop. If not, you will have to use a switch in between and some times
switch might be an issue.

one more thing, are you connected on static ip? If you are on dhcp, change
it to static ip and see.


On Tue, Jun 11, 2013 at 6:18 AM, Clark Pope  wrote:

> 
> > Date: Mon, 10 Jun 2013 18:00:21 -0400
> > From: ankan...@gmail.com
> > To: discuss-gnuradio@gnu.org
> > Subject: [Discuss-gnuradio] USRP_N200 unable to connect via vmplayer
> >
> > I have vmplayer virtual machine running on my computer as my system is
> > GPT partition style and which is not taking dual boot of any release of
> > ubuntu.
> >
> > I connect to an ethernet port to a USRP rx... and do a uhd_find_devices
> > .. it says no device found.. although I have a valid gnuradio distro
> > +uhd on my computer and it works fine when I am not using the USRP
> > though..
> >
> > Could it be because of the vm that I am using? Please suggest what do I
> > need to do!!
> >
> > this is my eth0 config-
> >
> > eth0 Link encap:Ethernet HWaddr 00:0c:29:23:94:4e
> > inet addr:192.168.10.1 Bcast:192.168.10.255 Mask:255.255.255.0
> > inet6 addr: fe80::20c:29ff:fe23:944e/64 Scope:Link
> > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> > RX packets:39419 errors:0 dropped:0 overruns:0 frame:0
> > TX packets:14888 errors:0 dropped:0 overruns:0 carrier:0
> > collisions:0 txqueuelen:1000
> > RX bytes:48827305 (48.8 MB) TX bytes:1521561 (1.5 MB)
> > Interrupt:19 Base address:0x2000
> >
> >
> > This shows up when I am doing my firmware update-
> >
> >
> > ankan@ubuntu
> :~/Downloads/uhd-images_003.005.001-release/share/uhd/images$
> > usrp_n2xx_simple_net_burner --addr 192.168.10.3 --fw usrp_n200_fw.bin
> > --fpga usrp_n200_r3_fpga.bin --auto_reboot
> > linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.005.003-78-g49a4929b
> >
> > Searching for USRP N2XX with IP address 192.168.10.3.
> > Error: No USRP N2XX found.
> >
> > my machine is 192.168.10.1 .. the usrp is on 192.168.10.3 via same
> > ethernet sw
> >
> >
> >
> > -Regards,
> > Ankan Roybardhan
> > University of Florida.
> >
>
> You're sure its not at the default address 192.168.10.2?
>
> Don't know if you have the same problem but I use a USB to GigE adapter
> from vmware player and I found that it ONLY works if I boot the VM with the
> interface that is connected to the USRP as the only active network
> connection. I can enable the network interface to the host OS after I boot
> and it still works but for some reason if the VMnetX interfaces are active
> at boot it messes up the ability to find the USRP.
>
> -Clark
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>



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

Re: [Discuss-gnuradio] USRP_N200 unable to connect via vmplayer

[Ankan Roybardhan]

1. I tried using vm bridged connection over NAT.. i assigned 192.168.10.1
and subnet 255.255.255.0 in the ubuntu network setting running on
vmplayer.. I am pretty much sure about the other USRP IP since.. i used
some other machine to do uhd_find_devices .. so check for their IPs..
2. My ethernet port is working fine on windows.. I though did not check it
on my vm.. bt hopefully it is working since it is recognizing the LAN..
3. The sw is perfectly fine tested OK.
4. I changed it from dhcp to manual ipv4 settings as 1. the problem
persists.. the device is on 192.168.10.3..
i did uhd_usrp_probe with --args=... it says the same.
could not find devices..

I feel there is a big issue with the vmplayer network settings with uhd...

-Ankan Roybardhan.


On Tue, Jun 11, 2013 at 1:29 AM, Karan Talasila  wrote:

> Hi,
> Check if your usrp is surely on 192.168.10.3. Run uhd_usrp_probe and
> check if it is giving any output. Do you have gigabit ethernet card on your
> laptop. If not, you will have to use a switch in between and some times
> switch might be an issue.
>
> one more thing, are you connected on static ip? If you are on dhcp, change
> it to static ip and see.
>
>
> On Tue, Jun 11, 2013 at 6:18 AM, Clark Pope  wrote:
>
>> 
>> > Date: Mon, 10 Jun 2013 18:00:21 -0400
>> > From: ankan...@gmail.com
>> > To: discuss-gnuradio@gnu.org
>> > Subject: [Discuss-gnuradio] USRP_N200 unable to connect via vmplayer
>> >
>> > I have vmplayer virtual machine running on my computer as my system is
>> > GPT partition style and which is not taking dual boot of any release of
>> > ubuntu.
>> >
>> > I connect to an ethernet port to a USRP rx... and do a uhd_find_devices
>> > .. it says no device found.. although I have a valid gnuradio distro
>> > +uhd on my computer and it works fine when I am not using the USRP
>> > though..
>> >
>> > Could it be because of the vm that I am using? Please suggest what do I
>> > need to do!!
>> >
>> > this is my eth0 config-
>> >
>> > eth0 Link encap:Ethernet HWaddr 00:0c:29:23:94:4e
>> > inet addr:192.168.10.1 Bcast:192.168.10.255 Mask:255.255.255.0
>> > inet6 addr: fe80::20c:29ff:fe23:944e/64 Scope:Link
>> > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> > RX packets:39419 errors:0 dropped:0 overruns:0 frame:0
>> > TX packets:14888 errors:0 dropped:0 overruns:0 carrier:0
>> > collisions:0 txqueuelen:1000
>> > RX bytes:48827305 (48.8 MB) TX bytes:1521561 (1.5 MB)
>> > Interrupt:19 Base address:0x2000
>> >
>> >
>> > This shows up when I am doing my firmware update-
>> >
>> >
>> > ankan@ubuntu
>> :~/Downloads/uhd-images_003.005.001-release/share/uhd/images$
>> > usrp_n2xx_simple_net_burner --addr 192.168.10.3 --fw usrp_n200_fw.bin
>> > --fpga usrp_n200_r3_fpga.bin --auto_reboot
>> > linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.005.003-78-g49a4929b
>> >
>> > Searching for USRP N2XX with IP address 192.168.10.3.
>> > Error: No USRP N2XX found.
>> >
>> > my machine is 192.168.10.1 .. the usrp is on 192.168.10.3 via same
>> > ethernet sw
>> >
>> >
>> >
>> > -Regards,
>> > Ankan Roybardhan
>> > University of Florida.
>> >
>>
>> You're sure its not at the default address 192.168.10.2?
>>
>> Don't know if you have the same problem but I use a USB to GigE adapter
>> from vmware player and I found that it ONLY works if I boot the VM with the
>> interface that is connected to the USRP as the only active network
>> connection. I can enable the network interface to the host OS after I boot
>> and it still works but for some reason if the VMnetX interfaces are active
>> at boot it messes up the ability to find the USRP.
>>
>> -Clark
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
>
> --
> Regards
> Karan Talasila
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] USRP_N200 unable to connect via vmplayer

[Josh Blum]

On 06/11/2013 02:19 AM, Ankan Roybardhan wrote:
> 1. I tried using vm bridged connection over NAT.. i assigned 192.168.10.1
> and subnet 255.255.255.0 in the ubuntu network setting running on
> vmplayer.. I am pretty much sure about the other USRP IP since.. i used
> some other machine to do uhd_find_devices .. so check for their IPs..
> 2. My ethernet port is working fine on windows.. I though did not check it
> on my vm.. bt hopefully it is working since it is recognizing the LAN..
> 3. The sw is perfectly fine tested OK.
> 4. I changed it from dhcp to manual ipv4 settings as 1. the problem
> persists.. the device is on 192.168.10.3..
> i did uhd_usrp_probe with --args=... it says the same.
> could not find devices..
> 
> I feel there is a big issue with the vmplayer network settings with uhd...

Well, can you ping the USRP from the VM? That would eliminate the
question of uhd and UDP sockets.

Can you ping another device with a static IP though the VM, like a
router that is connected to the same network interface as the USRP?

-josh

> 
> -Ankan Roybardhan.
> 
> 
> On Tue, Jun 11, 2013 at 1:29 AM, Karan Talasila  wrote:
> 
>> Hi,
>> Check if your usrp is surely on 192.168.10.3. Run uhd_usrp_probe and
>> check if it is giving any output. Do you have gigabit ethernet card on your
>> laptop. If not, you will have to use a switch in between and some times
>> switch might be an issue.
>>
>> one more thing, are you connected on static ip? If you are on dhcp, change
>> it to static ip and see.
>>
>>
>> On Tue, Jun 11, 2013 at 6:18 AM, Clark Pope  wrote:
>>
>>> 
 Date: Mon, 10 Jun 2013 18:00:21 -0400
 From: ankan...@gmail.com
 To: discuss-gnuradio@gnu.org
 Subject: [Discuss-gnuradio] USRP_N200 unable to connect via vmplayer

 I have vmplayer virtual machine running on my computer as my system is
 GPT partition style and which is not taking dual boot of any release of
 ubuntu.

 I connect to an ethernet port to a USRP rx... and do a uhd_find_devices
 .. it says no device found.. although I have a valid gnuradio distro
 +uhd on my computer and it works fine when I am not using the USRP
 though..

 Could it be because of the vm that I am using? Please suggest what do I
 need to do!!

 this is my eth0 config-

 eth0 Link encap:Ethernet HWaddr 00:0c:29:23:94:4e
 inet addr:192.168.10.1 Bcast:192.168.10.255 Mask:255.255.255.0
 inet6 addr: fe80::20c:29ff:fe23:944e/64 Scope:Link
 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
 RX packets:39419 errors:0 dropped:0 overruns:0 frame:0
 TX packets:14888 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:1000
 RX bytes:48827305 (48.8 MB) TX bytes:1521561 (1.5 MB)
 Interrupt:19 Base address:0x2000


 This shows up when I am doing my firmware update-


 ankan@ubuntu
>>> :~/Downloads/uhd-images_003.005.001-release/share/uhd/images$
 usrp_n2xx_simple_net_burner --addr 192.168.10.3 --fw usrp_n200_fw.bin
 --fpga usrp_n200_r3_fpga.bin --auto_reboot
 linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.005.003-78-g49a4929b

 Searching for USRP N2XX with IP address 192.168.10.3.
 Error: No USRP N2XX found.

 my machine is 192.168.10.1 .. the usrp is on 192.168.10.3 via same
 ethernet sw



 -Regards,
 Ankan Roybardhan
 University of Florida.

>>>
>>> You're sure its not at the default address 192.168.10.2?
>>>
>>> Don't know if you have the same problem but I use a USB to GigE adapter
>>> from vmware player and I found that it ONLY works if I boot the VM with the
>>> interface that is connected to the USRP as the only active network
>>> connection. I can enable the network interface to the host OS after I boot
>>> and it still works but for some reason if the VMnetX interfaces are active
>>> at boot it messes up the ability to find the USRP.
>>>
>>> -Clark
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>
>>
>>
>> --
>> Regards
>> Karan Talasila
>>
> 
> 
> 
> ___
> 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