Re: [Discuss-gnuradio] USRP2 start/stop issues
Hi,
> From: Josh Blum
> >>
> >>> Please pull from http://gnuradio.org/git/eb.git u2-hang
> >> This has been merged into the master branch.
> >>
> >> Johnathan
> >
> > svn trunk ?
> >
>
> The svn trunk has been unofficially deprecated since august third.
>
> http://www.mail-archive.com/discuss-gnuradio@gnu.org/msg20442.html
>
> -Josh
At Third August, Jonathan wrote :
{
We are using the git-svn gateway to mirror Subversion trunk commits
into the the above repository, and any git commits we manually push
into the above repository will become check-ins back into the
Subversion trunk. (This process is working but does not yet operate
automatically.)
}
I think the process is still not working. So, how we will know how
(for example) Eric solved USRP2 stop problem? What were the
modifications and on what files ?
Any suggestions or help ?
How to browse git files and modifications ? I dont see it in the Wiki pages.
Best Regards,
Firas
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 start/stop issues
Nice job all! Sent from my Verizon Wireless BlackBerry -Original Message- From: Tom Rondeau Date: Sat, 5 Sep 2009 17:26:13 To: Eric Blossom; Tom Rondeau; GNURadio Discussion List; Johnathan Corgan Subject: Re: [Discuss-gnuradio] USRP2 start/stop issues On Fri, Sep 4, 2009 at 7:14 AM, Eric Blossom wrote: > On Tue, Sep 01, 2009 at 03:58:32PM -0700, Eric Blossom wrote: >> On Tue, Sep 01, 2009 at 06:23:24PM -0400, Tom Rondeau wrote: >> > I have an application where I have to start and stop the USRP2 >> > multiple times at various points, but I've been having trouble getting >> > it to work. I traced it down to see that when the stop control message >> > is sent, the host never processes the reply pack from the USRP2. Using >> > Wireshark, I can see that this packet is being sent. After the failure >> > of the stop command, the remaining commands to restart the USRP2 and >> > set its parameters fail. >> > >> > To make this easier to debug, I found out that the simple program >> > below exercises the problem nicely. To see the failures, I just print >> > out the success message from "usrp2::impl::stop_rx_streaming" and from >> > "usrp2::impl::start_rx_streaming" (in /usrp2/host/lib/usrp2_impl.cc). >> > This is what happens: >> > >> > usrp2::stop_rx_streaming: success=1 >> > usrp2::start_rx_streaming: success=1 >> > usrp2::stop_rx_streaming: success=0 >> > usrp2::start_rx_streaming: success=0 >> > usrp2::stop_rx_streaming: success=0 >> > >> > The first stop_rx_streaming comes during the initialization of the >> > USRP2 to make sure its not streaming yet. >> > >> > Strangely (or maybe not; I can think of a some good reasons for this >> > behavior), when you set the "rate" variable to above 300 to slow down >> > the transmissions, everything works fine. At rate=200 it's flaky; >> > sometimes it works and sometimes it doesn't. So there seems to be some >> > timing issue involved. >> > >> > I've been looking and feel like I'm getting close to an answer, but it >> > keeps escaping me. Any ideas on what's causing this? >> > > It's fixed! I ran your test case 500 times w/o failure. > > There was a race in the code that notified the caller when the reply > came in. I also used your "don't enqueue when trying to stop" idea too. > > Please pull from http://gnuradio.org/git/eb.git u2-hang > > Eric > Hey. I thought I hit both you and Johnathan with a thank you email, but looking back, looks like it only went to Corgan. The fix works, so I'm well on my way with what I'm trying to do now. Thank you very much for the quick turnaround on this. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 start/stop issues
On Sat, Sep 05, 2009 at 05:26:13PM -0400, Tom Rondeau wrote: > On Fri, Sep 4, 2009 at 7:14 AM, Eric Blossom wrote: > > On Tue, Sep 01, 2009 at 03:58:32PM -0700, Eric Blossom wrote: > > > > It's fixed! I ran your test case 500 times w/o failure. > > > > There was a race in the code that notified the caller when the reply > > came in. I also used your "don't enqueue when trying to stop" idea too. > > > > Please pull from http://gnuradio.org/git/eb.git u2-hang > > > > Eric > > > > Hey. I thought I hit both you and Johnathan with a thank you email, > but looking back, looks like it only went to Corgan. > > The fix works, so I'm well on my way with what I'm trying to do now. > Thank you very much for the quick turnaround on this. > > Tom You're welcome. The funny thing is that the bug has been there since the beginning but seems to have only recently raised its head. I'm not sure if there's been a kernel upgrade along the way that sped up the path we're executing or what. Glad it's fixed in any case. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 start/stop issues
On Fri, Sep 4, 2009 at 7:14 AM, Eric Blossom wrote: > On Tue, Sep 01, 2009 at 03:58:32PM -0700, Eric Blossom wrote: >> On Tue, Sep 01, 2009 at 06:23:24PM -0400, Tom Rondeau wrote: >> > I have an application where I have to start and stop the USRP2 >> > multiple times at various points, but I've been having trouble getting >> > it to work. I traced it down to see that when the stop control message >> > is sent, the host never processes the reply pack from the USRP2. Using >> > Wireshark, I can see that this packet is being sent. After the failure >> > of the stop command, the remaining commands to restart the USRP2 and >> > set its parameters fail. >> > >> > To make this easier to debug, I found out that the simple program >> > below exercises the problem nicely. To see the failures, I just print >> > out the success message from "usrp2::impl::stop_rx_streaming" and from >> > "usrp2::impl::start_rx_streaming" (in /usrp2/host/lib/usrp2_impl.cc). >> > This is what happens: >> > >> > usrp2::stop_rx_streaming: success=1 >> > usrp2::start_rx_streaming: success=1 >> > usrp2::stop_rx_streaming: success=0 >> > usrp2::start_rx_streaming: success=0 >> > usrp2::stop_rx_streaming: success=0 >> > >> > The first stop_rx_streaming comes during the initialization of the >> > USRP2 to make sure its not streaming yet. >> > >> > Strangely (or maybe not; I can think of a some good reasons for this >> > behavior), when you set the "rate" variable to above 300 to slow down >> > the transmissions, everything works fine. At rate=200 it's flaky; >> > sometimes it works and sometimes it doesn't. So there seems to be some >> > timing issue involved. >> > >> > I've been looking and feel like I'm getting close to an answer, but it >> > keeps escaping me. Any ideas on what's causing this? >> > > It's fixed! I ran your test case 500 times w/o failure. > > There was a race in the code that notified the caller when the reply > came in. I also used your "don't enqueue when trying to stop" idea too. > > Please pull from http://gnuradio.org/git/eb.git u2-hang > > Eric > Hey. I thought I hit both you and Johnathan with a thank you email, but looking back, looks like it only went to Corgan. The fix works, so I'm well on my way with what I'm trying to do now. Thank you very much for the quick turnaround on this. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] A basic but critical problem in beginning of python code
Josh & others： Thanks for your help, I am just use the first way under your mentioned, means I modified a generated py file, and I use start function instead run(ture) function in the last line. But, after this job,the items added in GRC before is not displayed anymore.(I used a slider item to control the freq, after change run() to start() in the last line, the slider is missing while executing) 2009/9/5 Josh Blum > In the wx gui code (generated by grc), the last line in the py file is > tb.Run(True). This effectively calls start() on the flow graph and blocks in > the wx main loop: > > ---from top_block_gui.py--- > #start flow graph > if start: self.start() > #blocking main loop > self._app.MainLoop() > > For a wxgui app, you have to block in MainLoop(). However > > A) One option is to make your own threading.Thread class and pass it an > instance of your top block. Your thread will run in the background while the > main thread blocks at MainLoop(). > > B) An even better idea would be to make your own grc block wrapper that > will invoke this thread. You dont need to have an actual gnuradio block in > this xml wrapper, any python code is possible. A great example is the xmlrpc > server block: > http://gnuradio.org/trac/browser/gnuradio/trunk/grc/blocks/xmlrpc_server.xml > > With option *A*: this would require modifications to a generated py file. > If you generate the file again, you have to re-do the modifications. > > However, with option *B*: grc can generate the py file with your thread + > custom logic. All the information is captured in the saved grc file, so you > do not need to modify the "output py file". > > -Josh > > > nansai hu wrote: > >> So that is the reason for use .run() the gui will display if you py file >> is >> modified by a grc file, but if use the .start() function, no gui display >> even in same program? >> >> if it is ture,how can I add some logic after the program started? >> I mean if I use start() function ,the code after start() could be executed >> (use run function these code could not be executed),but the GUI silde or >> ratiobottom item which add to file by GRC previously could not be >> displayed? >> >> Is there anyway to have both GUI item and some logic after program could >> be >> available in same time? >> >> 2009/9/5 Josh Blum >> >> run() is a blocking call. >>> start() is a non-blocking call. >>> >>> Also, I believe run() will exit when a block returns -1 in its work >>> method. >>> FYI >>> >>> -Josh >>> >>> nansai hu wrote: >>> >>> When run a python script file, as we know main function will be run first. We send the class to a object "tb",for instance. Then we have two ways to let the program run. One is call tb.run() function,and other is call tb.start() function.Could somebody told me the difference bewteen these? In my coding experience, use .run() the gui will display if you py file is modified by a grc file, but if use the .start() function, no gui display even in same program. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] A basic but critical problem in beginning of python code
In the wx gui code (generated by grc), the last line in the py file is tb.Run(True). This effectively calls start() on the flow graph and blocks in the wx main loop: ---from top_block_gui.py--- #start flow graph if start: self.start() #blocking main loop self._app.MainLoop() For a wxgui app, you have to block in MainLoop(). However A) One option is to make your own threading.Thread class and pass it an instance of your top block. Your thread will run in the background while the main thread blocks at MainLoop(). B) An even better idea would be to make your own grc block wrapper that will invoke this thread. You dont need to have an actual gnuradio block in this xml wrapper, any python code is possible. A great example is the xmlrpc server block: http://gnuradio.org/trac/browser/gnuradio/trunk/grc/blocks/xmlrpc_server.xml With option *A*: this would require modifications to a generated py file. If you generate the file again, you have to re-do the modifications. However, with option *B*: grc can generate the py file with your thread + custom logic. All the information is captured in the saved grc file, so you do not need to modify the "output py file". -Josh nansai hu wrote: So that is the reason for use .run() the gui will display if you py file is modified by a grc file, but if use the .start() function, no gui display even in same program? if it is ture,how can I add some logic after the program started? I mean if I use start() function ,the code after start() could be executed (use run function these code could not be executed),but the GUI silde or ratiobottom item which add to file by GRC previously could not be displayed? Is there anyway to have both GUI item and some logic after program could be available in same time? 2009/9/5 Josh Blum run() is a blocking call. start() is a non-blocking call. Also, I believe run() will exit when a block returns -1 in its work method. FYI -Josh nansai hu wrote: When run a python script file, as we know main function will be run first. We send the class to a object "tb",for instance. Then we have two ways to let the program run. One is call tb.run() function,and other is call tb.start() function.Could somebody told me the difference bewteen these? In my coding experience, use .run() the gui will display if you py file is modified by a grc file, but if use the .start() function, no gui display even in same program. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 start/stop issues
On Sat, Sep 5, 2009 at 07:27, Brian Padalino wrote: > SVN has the nice capability of fetching only a portion of the code > without requiring me to grab the entire code base. I find this > feature lacking in git. > > Can it be setup such that the accepted git master is mirrored in the > SVN repository even if the SVN repo doesn't see any real development > on it and is only a place to "stash" the current workings? I owe everyone on the list an update on what we've done transitioning from Subversion to Git; this should happen after the holiday here in the US. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] sample synchronization among diffrent USRP2s with seperate gigabit ethernet ports
Hi GRers, We are planning to build a wideband MIMO system with 2 or more USRP2s. Acording to the configuration in http://gnuradio.org/trac/wiki/USRP2GenFAQ#WhatarethedifferentwaysMIMOcanbesetupwithmorethanoneUSRP2 a MIMO cable or HUB is used for connecting multiple USRP2s and just one ethernet interface is used for connecting to host computer. The problem is data from multiple USRP2 is sharing the ethernet bandwidth which will certainly be a bottleneck limiting the maximum available bandwidth. What we are considering is parallelly use all the ethernet interfaces on the USRP2s for delievering sample to host computer. I guess for receiver side, this can be done through use common 10MHz clock reference and 1PPS time reference as well as timestamping the samples in FPGA. (Has this timestamping already been done? How to use it on host computer?) How about on transmitter side? How to synchronize the samples sent to USRP2s? Thanks in advance. Hanwen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] A basic but critical problem in beginning of python code
So that is the reason for use .run() the gui will display if you py file is modified by a grc file, but if use the .start() function, no gui display even in same program? if it is ture,how can I add some logic after the program started? I mean if I use start() function ,the code after start() could be executed (use run function these code could not be executed),but the GUI silde or ratiobottom item which add to file by GRC previously could not be displayed? Is there anyway to have both GUI item and some logic after program could be available in same time? 2009/9/5 Josh Blum > run() is a blocking call. > start() is a non-blocking call. > > Also, I believe run() will exit when a block returns -1 in its work method. > FYI > > -Josh > > nansai hu wrote: > >> When run a python script file, as we know main function will be run >> first. >> We send the class to a object "tb",for instance. Then we have two ways to >> let the program run. >> One is call tb.run() function,and other is call tb.start() function.Could >> somebody told me the difference bewteen these? >> >> In my coding experience, use .run() the gui will display if you py file is >> modified by a grc file, but if use the .start() function, no gui display >> even in same program. >> >> >> >> >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 start/stop issues
On Sat, Sep 5, 2009 at 2:59 AM, Josh Blum wrote: > > The svn trunk has been unofficially deprecated since august third. > > http://www.mail-archive.com/discuss-gnuradio@gnu.org/msg20442.html SVN has the nice capability of fetching only a portion of the code without requiring me to grab the entire code base. I find this feature lacking in git. Can it be setup such that the accepted git master is mirrored in the SVN repository even if the SVN repo doesn't see any real development on it and is only a place to "stash" the current workings? Thanks, Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP 2 on PowerPC - any issues?
On Fri, 4 Sep 2009 06:47:58 am Eric Blossom wrote: snipped > > This is interesting news. Hopefully it means that I will be able to get > > Gnuradio running on one of my hppa boxen :-). I recently acquired a well > > spec'd rp5470 that'd be perfect for the task. > > I suspect that we won't run on hppa since IIRC it has a virtual mapped > cache, which I suspect will kill our mmap-based circular buffer trick. > > If you've got some time, please try to build it --disable-usrp2 > --disable-gr-usrp2 on your hppa and let me know if it passes make check. > > FWIW, the rest of GNU Radio runs fine on PPC / big-endian machines, > just not the usrp2 interface. > > Eric Hi Eric et al, Gnu Radio 3.2.2 configures OK but falls over part way through make as per the quote below. I can't write software but I can break stuff!! Cheers, Geoff. > Making all in tests > make[4]: Entering directory > `/home/vk2tfg/gnuradio-3.2.2/gnuradio-core/src/tests' g++ -DHAVE_CONFIG_H > -I. -I../../.. -DOMNITHREAD_POSIX=1 -I/usr/include > -I/home/vk2tfg/gnuradio-3.2.2/omnithread > -I/home/vk2tfg/gnuradio-3.2.2/gnuradio-core/src/lib/runtime > -I/home/vk2tfg/gnuradio-3.2.2/gnuradio-core/src/lib/general > -I/home/vk2tfg/gnuradio-3.2.2/gnuradio-core/src/lib/general > -I/home/vk2tfg/gnuradio-3.2.2/gnuradio-core/src/lib/gengen > -I/home/vk2tfg/gnuradio-3.2.2/gnuradio-core/src/lib/gengen > -I/home/vk2tfg/gnuradio-3.2.2/gnuradio-core/src/lib/filter > -I/home/vk2tfg/gnuradio-3.2.2/gnuradio-core/src/lib/filter > -I/home/vk2tfg/gnuradio-3.2.2/gnuradio-core/src/lib/missing > -I/home/vk2tfg/gnuradio-3.2.2/gnuradio-core/src/lib/reed-solomon > -I/home/vk2tfg/gnuradio-3.2.2/gnuradio-core/src/lib/viterbi > -I/home/vk2tfg/gnuradio-3.2.2/gnuradio-core/src/lib/io > -I/home/vk2tfg/gnuradio-3.2.2/gnuradio-core/src/lib/g72x > -I/home/vk2tfg/gnuradio-3.2.2/gnuradio-core/src/lib/swig > -I/home/vk2tfg/gnuradio-3.2.2/gnuradio-core/src/lib/hier > -I/home/vk2tfg/gnuradio-3.2.2/gnuradio-core/src/lib/swig > -I/home/vk2tfg/gnuradio-3.2.2/gruel/src/include > -I/home/vk2tfg/gnuradio-3.2.2/gruel/src/include-g -O2 -Wall > -Woverloaded-virtual -pthread -MT benchmark_dotprod_fff.o -MD -MP -MF > .deps/benchmark_dotprod_fff.Tpo -c -o benchmark_dotprod_fff.o > benchmark_dotprod_fff.cc mv -f .deps/benchmark_dotprod_fff.Tpo > .deps/benchmark_dotprod_fff.Po /bin/sh ../../../libtool --tag=CXX > --mode=link g++ -g -O2 -Wall -Woverloaded-virtual -pthread -o > benchmark_dotprod_fff benchmark_dotprod_fff.o > /home/vk2tfg/gnuradio-3.2.2/gnuradio-core/src/lib/libgnuradio-core.la > libtool: link: g++ -g -O2 -Wall -Woverloaded-virtual -pthread -o > .libs/benchmark_dotprod_fff benchmark_dotprod_fff.o > /home/vk2tfg/gnuradio-3.2.2/gnuradio-core/src/lib/.libs/libgnuradio-core.so > /home/vk2tfg/gnuradio-3.2.2/omnithread/.libs/libgromnithread.so > /home/vk2tfg/gnuradio-3.2.2/gruel/src/lib/.libs/libgruel.so -L/usr/lib > -lboost_thread-d -lrt /usr/lib/libfftw3f.so -lgsl -lgslcblas -pthread > /home/vk2tfg/gnuradio-3.2.2/gnuradio-core/src/lib/.libs/libgnuradio-core.so >: undefined reference to `__sync_val_compare_and_swap_4' > /home/vk2tfg/gnuradio-3.2.2/gruel/src/lib/.libs/libgruel.so: undefined > reference to `boost::thread::start_thread()' > /home/vk2tfg/gnuradio-3.2.2/gnuradio-core/src/lib/.libs/libgnuradio-core.so >: undefined reference to `boost::this_thread::interruption_point()' > /home/vk2tfg/gnuradio-3.2.2/gruel/src/lib/.libs/libgruel.so: undefined > reference to > `boost::this_thread::disable_interruption::~disable_interruption()' > /home/vk2tfg/gnuradio-3.2.2/gnuradio-core/src/lib/.libs/libgnuradio-core.so >: undefined reference to `boost::detail::get_current_thread_data()' > /home/vk2tfg/gnuradio-3.2.2/gnuradio-core/src/lib/.libs/libgnuradio-core.so >: undefined reference to `boost::this_thread::interruption_requested()' > /home/vk2tfg/gnuradio-3.2.2/gruel/src/lib/.libs/libgruel.so: undefined > reference to `boost::thread::interrupt()' > /home/vk2tfg/gnuradio-3.2.2/gnuradio-core/src/lib/.libs/libgnuradio-core.so >: undefined reference to `__sync_fetch_and_add_4' > /home/vk2tfg/gnuradio-3.2.2/gruel/src/lib/.libs/libgruel.so: undefined > reference to > `boost::this_thread::disable_interruption::disable_interruption()' > collect2: ld returned 1 exit status > make[4]: *** [benchmark_dotprod_fff] Error 1 > make[4]: Leaving directory > `/home/vk2tfg/gnuradio-3.2.2/gnuradio-core/src/tests' make[3]: *** > [all-recursive] Error 1 > make[3]: Leaving directory `/home/vk2tfg/gnuradio-3.2.2/gnuradio-core/src' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory `/home/vk2tfg/gnuradio-3.2.2/gnuradio-core' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/vk2tfg/gnuradio-3.2.2' > make: *** [all] Error 2 > vk2...@hppa:~/gnuradio-3.2.2$ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] A basic but critical problem in beginning of python code
nansai hu wrote: > > When run a python script file, as we know main function will be run first. > We send the class to a object "tb",for instance. Then we have two ways to > let the program run. > One is call tb.run() function,and other is call tb.start() function.Could > somebody told me the difference bewteen these? > > In my coding experience, use .run() the gui will display if you py file is > modified by a grc file, but if use the .start() function, no gui display > even in same program. > > tb.start will start the executing the program. tb.rum do two things; tb.start and tb.wait. tb.wait will keep the flow graph keep running. Adib -- View this message in context: http://www.nabble.com/A-basic-but-critical-problem-in-beginning-of-python-code-tp25304873p25305848.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
