[Discuss-gnuradio] Re starting the USRP/USRP2 through terminal.

2011-09-22 Thread sumitstop 

Is there any method to restart the USRP/USRP2 using commands on the terminal.

For example I run benchmark programs for Tx and some times I terminate them 
using Ctrl+z before the they terminate by themselves after the transmission
is over.
But when I again try to run another program I says "cant open usrp".
Then I manually switch off the power to usrp and restart.Then only I am able
to run any new program.

I was thinking if there is some terminal command to perform this task so
that I can include that in my script.

Are there any other options.:-)



-
Sumit Kr.
Research Assistant
Communication Research center
IIIT Hyderabad
India
-- 
View this message in context: 
http://old.nabble.com/Restarting-the-USRP-USRP2-through-terminal.-tp32503814p32503814.html
Sent from the GnuRadio mailing list archive at Nabble.com.


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

Re: [Discuss-gnuradio] Re starting the USRP/USRP2 through terminal.

2011-09-22 Thread Sanketh Kumar P 
why not try Ctrl+c instead of Ctrl+z ??
ctrl+z just stops the process right, whereas ctrl+c kills it.

On Thu, Sep 22, 2011 at 6:38 PM, sumitstop
wrote:

>
> Is there any method to restart the USRP/USRP2 using commands on the
> terminal.
>
> For example I run benchmark programs for Tx and some times I terminate them
> using Ctrl+z before the they terminate by themselves after the transmission
> is over.
> But when I again try to run another program I says "cant open usrp".
> Then I manually switch off the power to usrp and restart.Then only I am
> able
> to run any new program.
>
> I was thinking if there is some terminal command to perform this task so
> that I can include that in my script.
>
> Are there any other options.:-)
>
>
>
> -
> Sumit Kr.
> Research Assistant
> Communication Research center
> IIIT Hyderabad
> India
> --
> View this message in context:
> http://old.nabble.com/Restarting-the-USRP-USRP2-through-terminal.-tp32503814p32503814.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>



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

Re: [Discuss-gnuradio] different CPU loads with 2 similar GRC graphs

2011-09-22 Thread Michael Dickens 
On Sep 22, 2011, at 1:41 AM, Achilleas Anastasopoulos wrote:
> [source] --> [block A] -->[sink]
> |___^

Just to clarify ... is your graph:

connect (source, A, sink)
connect (source, sink)

I don't know for certain why the loads are different, but I can make some 
educated guesses.  But, I'm also happy to defer to others who might know 
better. - MLD


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

[Discuss-gnuradio] About gr.buffer

2011-09-22 Thread Zhonghua 

Hi every one,
Now I am trying to use gr.buffer. I wrote some very simple codes to 
test how to use gr.buffer correctly. The main codes are as below:
 self.u=gr.sig_source_c(1e4,gr.GR_SIN_WAVE,1e3,1)   #to 
create a sin source
 self.buf=gr.buffer(1000,gr.sizeof_gr_complex,self.u) 
#create a buffer by applying gr.buffer

 self.csink=gr.vector_sink_c()
 
self.connect(self.buf,self.csink)   
#send buffer volume to the sink


But unfortunately, I got a despondent error reply says: in method 
'buffer', argument 3 of type 'gr_block_sptr'. I looked up the gr_buffer 
class and found that the so called argument 3 is a link to a block which 
writes data to this buffer. As my understanding, the sig_source block 
should write data to the buffer so I write self.buf as above way. From 
the error hint, I ever thought perhaps the error just comes from the 
incorrect type. Because the sin_source object is pointed by the pointer 
type of "gr_sin_source_c_sptr". But how can I get an object that merely 
inherited from gr.block class? I tried to construct a class inherits 
from gr.block but there exists another error says that "'module' object 
has no attribute 'block' ".
I checked the internet but found nothing helpful. A surprising fact is 
that looks no one ever used gr.buffer in gnuradio by adopting python 
way. Is there anybody know how to use it correctly?

Your instruction is fairly appreciated.

Br,
Zhonghua




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

[Discuss-gnuradio] GNU Radio release cycle

2011-09-22 Thread Philip Balister 
Yesterday I realized I have no idea when Josh's cmake work will go into 
GNU Radio and be part of an actual release.


This is a big headache for me because I am updating the root file 
systems for the E100 at the moment and there is some stuff in the cmake 
branch that is useful for the E100 (such as being able to build and 
package GNU Radio companion). On the other hand, I can't cherry pick the 
best git repo/branch every time I want to make a new root file system 
for the E100. I really need some kind of deterministic release cycle so 
I know when I need to finish tasks and shepherd them into GNU Radio and 
have some confidence they will appear in a release.


Fortunately, other projects also have the same problem, so there are 
examples to work from. Since I've been working on getting all my u-boot 
patches upstream lately, I'll use them as an example:


http://www.denx.de/wiki/U-Boot/ReleaseCycle

This is based on the Linux kernel development cycle, which has become a 
very successful work flow.


So the workflow becomes:

1) A release every three months.
2) After each release, there is a period where new work is added.
3) After the merge window closes, only fixes are allowed.
4) A release occurs.

I'm not super attached to this model, other than I am familiar with the 
process already and the fewer things I need to remember, the better. It 
should serve as a starting point for discussion.


Philip

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

Re: [Discuss-gnuradio] About gr.buffer

2011-09-22 Thread Tom Rondeau 
On Thu, Sep 22, 2011 at 10:11 AM, Zhonghua  wrote:

> Hi every one,
>Now I am trying to use gr.buffer. I wrote some very simple codes to test
> how to use gr.buffer correctly. The main codes are as below:
> self.u=gr.sig_source_c(1e4,gr.**GR_SIN_WAVE,1e3,1)   #to
> create a sin source
> self.buf=gr.buffer(1000,gr.**sizeof_gr_complex,self.u) #create
> a buffer by applying gr.buffer
> self.csink=gr.vector_sink_c()
> self.connect(self.buf,self.**csink)
> #send buffer volume to the sink
>
> But unfortunately, I got a despondent error reply says: in method 'buffer',
> argument 3 of type 'gr_block_sptr'. I looked up the gr_buffer class and
> found that the so called argument 3 is a link to a block which writes data
> to this buffer. As my understanding, the sig_source block should write data
> to the buffer so I write self.buf as above way. From the error hint, I ever
> thought perhaps the error just comes from the incorrect type. Because the
> sin_source object is pointed by the pointer type of "gr_sin_source_c_sptr".
> But how can I get an object that merely inherited from gr.block class? I
> tried to construct a class inherits from gr.block but there exists another
> error says that "'module' object has no attribute 'block' ".
> I checked the internet but found nothing helpful. A surprising fact is that
> looks no one ever used gr.buffer in gnuradio by adopting python way. Is
> there anybody know how to use it correctly?
> Your instruction is fairly appreciated.
>
> Br,
> Zhonghua
>

The gr.buffer is not meant to be used this way. It's the data structure used
in the input and output ports of the blocks to move data. There's no reason
to use it in a flowgraph or anything like that.

What's your reason for wanting a buffer there in the first place? It's
likely that there is an actual block meant for your purpose.

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

[Discuss-gnuradio] Conference and Website

2011-09-22 Thread Tom Rondeau 
Hi everyone,
As you should be aware by now, we had our first GNU Radio Conference last
week at the University of Pennsylvania. We had a great turnout, and a lot of
fantastic interaction and participation by everyone there. A big THANK YOU
to everyone who came and participated! It was a huge success! And thanks to
the sponsors for helping put it together:
http://gnuradio.squarespace.com/gnu-radio-conference-2011/

We definitely plan on doing this annually, although due to some personal
circumstances, I will likely not be able to organize it like I did this
year. But I know others are stepping up. And while we held it in September
of this year, if we hear back from enough people with issues, we can think
about moving it. At least for Philadelphia, though, I think most people
would agree that we had great weather for the conference, which was one main
reason it happened when it did. It also just about marked the end of my
first year leading the project.

Shortly, I will be putting up a survey for those who attended for feedback
on the conference and what we can do next time.

Last night, I posted all of the presentations that I have on the conference
website:
http://gnuradio.squarespace.com/grc2011-dates/

These are actually being hosted from gnuradio.org:
http://gnuradio.org/redmine/projects/gnuradio/wiki/GRConf2011

We also recorded audio from each presenter. Once I've properly formatted and
edited them, I will put these online, too.

So thank you all again! Next year's should be bigger and better, and I hope
the great conversations we started this year continue on the mailing list
and lead to amazing things for the next conference.

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

Re: [Discuss-gnuradio] Conference and Website

2011-09-22 Thread Michael Dickens 
Thank you, Tom, for organizing the conference.  I certainly feel it was 
successful, and look forward to next year's.  Beyond the presentations -- which 
it's great to see up already -- would it be possible to post demos, or links to 
some repository containing the demos, that used GNU Radio / GRC?  I'm thinking 
specifically of Matt's that allowed the user to play with the channel for 
various encoder / decoder types -- those were really awesome & IMHO useful for 
anyone dealing with real-world wireless communications. - MLD


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

Re: [Discuss-gnuradio] Conference and Website

2011-09-22 Thread Tom Rondeau 
On Thu, Sep 22, 2011 at 11:12 AM, Michael Dickens  wrote:

> Thank you, Tom, for organizing the conference.  I certainly feel it was
> successful, and look forward to next year's.  Beyond the presentations --
> which it's great to see up already -- would it be possible to post demos, or
> links to some repository containing the demos, that used GNU Radio / GRC?
>  I'm thinking specifically of Matt's that allowed the user to play with the
> channel for various encoder / decoder types -- those were really awesome &
> IMHO useful for anyone dealing with real-world wireless communications. -
> MLD
>

Thanks for the reminder. Forgot about this last night. They are now
available as a tarball.

My plan is to make these into hierarchical blocks that will be put into the
GNU Radio source code so that it's easy for people to add a "radio
impairments" block to their simulations to compliment a channel simulation.

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

Re: [Discuss-gnuradio] memory leak problem with GNURadio/Python

2011-09-22 Thread Tom Rondeau 
On Thu, Sep 22, 2011 at 2:55 AM, Sanketh Kumar P wrote:

> after executing a GNURadio flowgraph for sometime (typically for abt
> 2-3mins) the code crashes and
> the following message is displayed.
>

We're going to need way more information than this to help you. This error
tells us almost nothing about where the problem might be.

Here's a helpful process. In the Python program, right at the top before any
functions are declared, put this in:

import os
print os.getpid()
raw_input()

That will print out the program's PID and pause it, waiting for you to hit
enter. In another terminal, run "gdb." Inside gdb, type:

attach 
c

Where the  is what was printed by the progra. The "c" tells the
debugger to continue. Now, go back to the program's window and hit enter.
When the crash occurs, gdb will pick it up. You can then type "bt" in gdb to
get a back trace of the program. This will help identify while line of what
file caused the error.

Tom





> '''
> *** glibc detected *** python: malloc(): memory corruption:
> 0x7f7b94002b00 ***
> === Backtrace: =
> /lib/x86_64-linux-gnu/libc.so.6(+0x79d7a)[0x7f7bae94bd7a]
> /lib/x86_64-linux-gnu/libc.so.6(__libc_malloc+0x6e)[0x7f7bae94e31e]
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6(_Znwm+0x1d)[0x7f7bad760e0d]
>
> /usr/local/lib/libgnuradio-core-3.4.1git.so.0(_ZNSt6vectorIfSaIfEEaSERKS1_+0x7b)[0x7f7badc71b9b]
>
> /usr/local/lib/python2.7/dist-packages/gnuradio/gr/_gnuradio_core_gengen.so(+0x11c65d)[0x7f7bab42f65d]
> python(PyEval_EvalFrameEx+0x361)[0x4965f1]
> python(PyEval_EvalFrameEx+0xb2f)[0x496dbf]
> === Memory map: 
> 0040-0062f000 r-xp  08:03 5899249
> /usr/bin/python2.7
> 0082e000-0082f000 r--p 0022e000 08:03 5899249
> /usr/bin/python2.7
> 0082f000-00897000 rw-p 0022f000 08:03 5899249
> /usr/bin/python2.7
> 00897000-008a9000 rw-p  00:00 0
> 014e3000-02266000 rw-p  00:00 0
> [heap]
> 7f7b9400-7f7b94021000 rw-p  00:00 0
> 7f7b94021000-7f7b9800 ---p  00:00 0
> ...
> ...
> ...
> '''
>
> please help me in rectifying it. thanx in advance
>
>
> ___
> 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] Conference and Website

2011-09-22 Thread Michael Dickens 
On Sep 22, 2011, at 11:40 AM, Tom Rondeau wrote:
> Thanks for the reminder. Forgot about this last night. They are now available 
> as a tarball.

Awesome; thanks.

> My plan is to make these into hierarchical blocks that will be put into the 
> GNU Radio source code so that it's easy for people to add a "radio 
> impairments" block to their simulations to compliment a channel simulation.

Great idea! - MLD


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

Re: [Discuss-gnuradio] Code Modify Help on Module gr-trellis

2011-09-22 Thread Tom Rondeau 
2011/9/21 SongLixing 

>  Hi,
>
> This is Song, a phd student in Computing School of USM. I'm using GNUraido
> to do some research in wireless channel coding. I try to extract some useful
> information from trellis_viterbi and then use this information as
> measurement in other functions.
>
> Currently, I have successfully get the information I want from the function
> viterbi_algorithm, which is in
> /gnuradio/gr-trellis/src/lib/core_algorithms.cc, and I added one more
> parameter in this function to output the information to upper
> class(trellis_viterbi_s.cc). What my problems now is that, I can not add one
> more output port to the gr.trellis_viterbi_s. All I want to do is that makes
> gr.trellis_viterbi_s has two output ports, both are outputing float, one is
> the measurement which has been caculated from viterbi_algorithm, another one
> is the decoded data which is float data but I will do some convert to short
> later.
>
> Could you give me some instructions about what I need to modify if I want
> to change one output port signal block to two output ports.
>
> Thanks,
>
> Lixing Song
>

Hi Song,
Because this block is auto-generated from a template, you really want to
edit /gr-trellis/src/lib/trellis_viterbi_X.cc.t.

It looks like this block is already set up to have multiple output streams,
so you'll have to work around what it's already doing to add what you want.

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

Re: [Discuss-gnuradio] different CPU loads with 2 similar GRC graphs

2011-09-22 Thread Achilleas Anastasopoulos 

Yes.

Achilleas

On 9/22/2011 9:45 AM, Michael Dickens wrote:

On Sep 22, 2011, at 1:41 AM, Achilleas Anastasopoulos wrote:

[source] -->  [block A] -->[sink]
 |___^


Just to clarify ... is your graph:

connect (source, A, sink)
connect (source, sink)

I don't know for certain why the loads are different, but I can make some 
educated guesses.  But, I'm also happy to defer to others who might know 
better. - MLD


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

Re: [Discuss-gnuradio] different CPU loads with 2 similar GRC graphs

2011-09-22 Thread Nick Foster 
Well, in answer to question 1, you don't need a throttle to avoid system
instability. You really use the throttle to keep your computer from becoming
entirely unresponsive when you have multiple threads with high priority
running simultaneously as fast as they can.

I don't know the answer to question 2 -- I suspect to find the answer you're
going to have to do some deep hunting in the scheduler.

--n

On Thu, Sep 22, 2011 at 8:06 AM, Achilleas Anastasopoulos  wrote:

> Yes.
>
> Achilleas
>
>
> On 9/22/2011 9:45 AM, Michael Dickens wrote:
>
>> On Sep 22, 2011, at 1:41 AM, Achilleas Anastasopoulos wrote:
>>
>>> [source] -->  [block A] -->[sink]
>>> |___^
>>>
>>
>> Just to clarify ... is your graph:
>>
>> connect (source, A, sink)
>> connect (source, sink)
>>
>> I don't know for certain why the loads are different, but I can make some
>> educated guesses.  But, I'm also happy to defer to others who might know
>> better. - MLD
>>
>
> __**_
> 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] Roadmap created for release v3.5

2011-09-22 Thread Tom Rondeau 
Johnathan, Josh, and I had a great discussion at the end of the conference
last week to outline what needs to be done in GNU Radio for the next version
release. I have just updated our roadmap on gnuradio.org (
http://gnuradio.org/redmine/projects/gnuradio/versions/19) that lists all of
the bugs and features we need to attack.

This is mostly so everyone knows what's going on. Most of these tasks have
been assigned to either myself, Josh, or Johnathan, and I think we can
handle them in a timely manner. But! Just as an advertisement, there are
still other bugs out there that need attention. Some of them are serious
issues that need to be discussed, but others can be handled independently.
Often, getting to them is just a matter of time and energy more than
anything.

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

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

Re: [Discuss-gnuradio] one liner grc fix - please cherry pick

2011-09-22 Thread Tom Rondeau 
On Fri, Sep 16, 2011 at 1:19 PM, Josh Blum  wrote:

>
> http://gnuradio.org/cgit/jblum.git/commit/?h=fix_grc_port_dup&id=726bf6444ad4b12ab86949ad253e9c59d9ad7208
>
> -josh
>


Done. Applied to maint. The master and next branches have also been updated.

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

Re: [Discuss-gnuradio] different CPU loads with 2 similar GRC graphs

2011-09-22 Thread Michael Dickens 
On Sep 22, 2011, at 1:00 PM, Nick Foster wrote:
> Well, in answer to question 1, you don't need a throttle to avoid system 
> instability. You really use the throttle to keep your computer from becoming 
> entirely unresponsive when you have multiple threads with high priority 
> running simultaneously as fast as they can

That would make an interesting test for Achilleas: Do test 1 using real-time 
priority & see if that locks up the system or not.

> I don't know the answer to question 2 -- I suspect to find the answer you're 
> going to have to do some deep hunting in the scheduler.

Let me see if I can work anything out:

Roughly: In the TPB model when "progress is made" for a given block (e.g., data 
is generated or consumed), the appropriate thread(s) containing adjacent blocks 
are signaled (IIRC, from waiting on a condition)(e.g., if data is consumed then 
the prior block(s) [those generating the data] are notified).  When those 
threads wake up, they check to see whether or not they have enough input data 
and output space to do processing.  This check is done by the TPB "scheduler" 
-- it's an algorithm that you can read about in 
"gnuradio-core/src/lib/runtime/gr_block_executor.cc" if you really want to.  A 
given block cannot do processing until enough input data and output space area 
simultaneously available, and the TPB scheduler tries to maximize data 
processing.

For case #1, the signaling and scheduler's job is simple because each block is 
connected only to adjacent blocks.  If you were to plot out the block execution 
pattern, I'd guess it was something like:

(source == 1; sink == 2; E == "executing"; W == "waiting"):

Thread  Time ->
   1E E E E E ...
   AW E E E E ...
   2W W E E E ...

For this case data is well-pipelined -- A can process as soon as 1 is finished, 
and 2 can process as soon as A is finished.  Assuming A is CPU intensive & the 
graph isn't otherwise throttled, then each block could easily saturate a single 
CPU (if that's how much processing each requires).

For case #2, the signaling and scheduler's job is complicated by the dual paths 
from source to sink.  If you were to plot out the block execution pattern, I'd 
guess it was something like:

(X == "waiting, unsuccessful execution, and then more waiting"; I switch from 
"W" to "X" because of the signaling between threads):

Thread  Time ->
   1E E X E E X E E ... 
   AW E E X E E X E ...
   2W X E X X E X X ...

So, in this case because of the odd data shuffling, you'll see somewhat less 
than full CPU usage (on the average).  The above "diagram" assumes that 1 is 
generating a sizable chunk of data (relative to the total buffer size), such 
that it can do one or two writes before its output buffer is full (that's 
roughly how the TPB scheduler works, btw).  The actual wait time-duration I 
think depends primarily on how long it takes A to do processing.  Either way: 
The basic idea is that the data is not well-pipelined, and hence there are 
waits that reduce the average CPU usage [another possible factor is how much 
overhead time is spent during X's (emerging from wait, checking for processing, 
then going back into wait)].

I hope this is reasonably accurate, makes sense, and helps! - MLD


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

Re: [Discuss-gnuradio] Sample fast and upload after

2011-09-22 Thread Per Zetterberg 

Marc Epard has uploaded code for this:  https://public.me.com/mepard

I haven't had time to try it myself yet. I meet people all the time who think 
it would be really useful to have this kind of functionality on both RX and TX.

BR/
Per


From: discuss-gnuradio-bounces+perz=kth...@gnu.org 
[discuss-gnuradio-bounces+perz=kth...@gnu.org] on behalf of Matt Ettus 
[m...@ettus.com]
Sent: Wednesday, September 21, 2011 6:01 PM
To: mipro...@gmail.com
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Sample fast and upload after

You would need to modify the FPGA to do this.  However, some other people have 
done that and may have code available.  Check the email archive on the 
usrp-users list.

Matt

On Tue, Sep 20, 2011 at 11:21 AM, 
mailto:mipro...@gmail.com>> wrote:
Hi all,
Is it possible with GNURadio to sample at high speed, store the samples in FPGA 
memory, and have the PC retrieve the sample after? We need to sample at higher 
speed than the Ethernet can handle. I'm wondering if this can be done without a 
USRP FPGA code change.

Ben


___
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] Sample fast and upload after

2011-09-22 Thread Marc Epard 
It's out of date, though. We've had our system and libraries frozen for a while 
as we were finishing a project. I'm in the process of updating it to the latest 
UHD and will post when I'm finished.

-Marc

On Sep 22, 2011, at 3:17 PM, Per Zetterberg wrote:

> 
> Marc Epard has uploaded code for this:  https://public.me.com/mepard
> 
> I haven't had time to try it myself yet. I meet people all the time who think 
> it would be really useful to have this kind of functionality on both RX and 
> TX.
> 
> BR/
> Per
> 
> 
> From: discuss-gnuradio-bounces+perz=kth...@gnu.org 
> [discuss-gnuradio-bounces+perz=kth...@gnu.org] on behalf of Matt Ettus 
> [m...@ettus.com]
> Sent: Wednesday, September 21, 2011 6:01 PM
> To: mipro...@gmail.com
> Cc: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] Sample fast and upload after
> 
> You would need to modify the FPGA to do this.  However, some other people 
> have done that and may have code available.  Check the email archive on the 
> usrp-users list.
> 
> Matt
> 
> On Tue, Sep 20, 2011 at 11:21 AM, 
> mailto:mipro...@gmail.com>> wrote:
> Hi all,
> Is it possible with GNURadio to sample at high speed, store the samples in 
> FPGA memory, and have the PC retrieve the sample after? We need to sample at 
> higher speed than the Ethernet can handle. I'm wondering if this can be done 
> without a USRP FPGA code change.
> 
> Ben
> 
> 
> ___
> 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] Work on USRP source and sink stream tagging for gr-uhd

2011-09-22 Thread Josh Blum 
I have been working on support of tag handling for the USRP source and
sink blocks in gr-uhd. I will be adding some test and example code, but
if anyone cares to experiment, see my uhd_features branch on jblum.git
http://gnuradio.org/cgit/jblum.git/log/?h=uhd_features

Rather than describe, its easier to paste these excerpts from the docs:

 * RX Stream tagging:
 *
 * The following tag keys will be produced by the work function:
 *  - pmt::pmt_string_to_symbol("rx_time")
 *
 * The timstamp tag value is a pmt tuple of the following:
 * (uint64 seconds, and double fractional seconds).
 * A timestamp tag is produced at start() and after overflows.


 * TX Stream tagging:
 *
 * The following tag keys will be consumed by the work function:
 *  - pmt::pmt_string_to_symbol("tx_sob")
 *  - pmt::pmt_string_to_symbol("tx_eob")
 *  - pmt::pmt_string_to_symbol("tx_time")
 *
 * The sob and eob (start and end of burst) tag values are pmt booleans.
 * When present, burst tags should be set to true (pmt::PMT_T).
 *
 * The timstamp tag value is a pmt tuple of the following:
 * (uint64 seconds, and double fractional seconds).

-Josh

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

[Discuss-gnuradio] Using GnuRadio Commands inside GRC

2011-09-22 Thread adeel anwar 
Hi,

Simulink have a block named "Matlab Function", in which user can write
Matlab code and use it just like other simulink blocks,so does GRC have a
smilar block which supports gnuradio commands/function (for which GRC blocks
are not yet written ) or is such block planned in the future?

Regards,

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

Re: [Discuss-gnuradio] Using GnuRadio Commands inside GRC

2011-09-22 Thread Josh Blum 


On 09/22/2011 09:05 PM, adeel anwar wrote:
> Hi,
> 
> Simulink have a block named "Matlab Function", in which user can write
> Matlab code and use it just like other simulink blocks,so does GRC have a
> smilar block which supports gnuradio commands/function (for which GRC blocks
> are not yet written ) or is such block planned in the future?
> 

Well, there is no mscript, its all python.

You can call *any* python function from a parameter in GRC. Example
using the gr.firdes filter design functions:
http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioCompanion#Filter-Design

If you want to make a custom block, you can do that in python or C++,
but there is not support to design that from inside the gui.

-Josh

Sent from my toaster

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

Re: [Discuss-gnuradio] Using GnuRadio Commands inside GRC

2011-09-22 Thread adeel anwar 
U mentioned about filter-design but calling those python functions only
generates/loads input parameter when execution
of flow graph starts (coefficients for filters).
I am asking about the possibility to use these function for processing or
any block in GRC that supports code writing?
Both Simulink and Labview have such blocks for code


On Fri, Sep 23, 2011 at 9:17 AM, Josh Blum  wrote:

>
>
> On 09/22/2011 09:05 PM, adeel anwar wrote:
> > Hi,
> >
> > Simulink have a block named "Matlab Function", in which user can write
> > Matlab code and use it just like other simulink blocks,so does GRC have a
> > smilar block which supports gnuradio commands/function (for which GRC
> blocks
> > are not yet written ) or is such block planned in the future?
> >
>
> Well, there is no mscript, its all python.
>
> You can call *any* python function from a parameter in GRC. Example
> using the gr.firdes filter design functions:
>
> http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioCompanion#Filter-Design
>
> If you want to make a custom block, you can do that in python or C++,
> but there is not support to design that from inside the gui.
>
> -Josh
>
> Sent from my toaster
>
> ___
> 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