Yes, you should be able to start and stop streaming using timed commands on the E310.
Are you using the Release 4 image? --Neel Pandeya On 5 June 2017 at 11:54, Marcus Müller <marcus.muel...@ettus.com> wrote: > Hi Jessica, > > not 100% sure you're right about timed commands not being supported on the > E310 – yes, things like tuning and setting the gain can't be timed on the > E310, but I thought stream commands should work. Will check. > > Best regards, > > Marcus > > On 02.06.2017 19:16, Jessica Iwamoto wrote: > > Hi all, > > > > We’re trying to implement a fast sweep over a range of frequencies on the > E310. Currently, I have a Python block that takes in a stream from the USRP > Source, counts up the number of samples, and after receiving n samples, > issues a stream command to the USRP Source to receive n more samples. There > is currently a delay (of a few ms) between when the stream command is > issued and when the work function of my custom block is called, and we are > trying to find ways to shorten this delay. We can’t use timed commands > because they are not supported in the E310 and it doesn’t look like you can > queue up a series of stream commands either. We also can’t use a custom C++ > block because of the issues discussed previously in this email thread. > > > > Does anyone have ideas on what to try? Or, could you point me to the > relevant UHD code, as it is a bit confusing to follow? Also, are there any > plans to add support for timed commands in the E310 or for a queue of > stream commands? > > > > Thank you, > > Jessica > > > > > > *From:* Discuss-gnuradio [mailto:discuss-gnuradio- > bounces+jessica.iwamoto=aero....@gnu.org > <discuss-gnuradio-bounces+jessica.iwamoto=aero....@gnu.org>] *On Behalf > Of *Marcus Müller > *Sent:* Wednesday, May 24, 2017 12:26 PM > *To:* discuss-gnuradio@gnu.org; Philip Balister <phi...@opensdr.com> > <phi...@opensdr.com> > *Subject:* Re: [Discuss-gnuradio] Custom C++ blocks on E310 > > > > Hi Jessica, > > that's really interesting! > > It means that the problem only happens when you use your compiler to build > your C++ blocks, but not when only using the GNU Radio that's already part > of your image. Not quite sure what that entails; maybe it means that > openembedded builds broken SDKs... That shouldn't happen. The other thing I > could think of would be a slight misconfiguration of the compiler (or the > linker). Maybe Philip has an idea! > > Best regards, > > Marcus > > > > > > On 24.05.2017 20:51, Jessica Iwamoto wrote: > > Hi all, > > > > I never found the solution to this problem, but I ended up using a work > around by writing my custom blocks in Python instead of C++. > > > > Jessica > > > > *From:* Discuss-gnuradio [mailto:discuss-gnuradio- > bounces+jessica.iwamoto=aero....@gnu.org > <discuss-gnuradio-bounces+jessica.iwamoto=aero....@gnu.org>] *On Behalf > Of *Jessica Iwamoto > *Sent:* Monday, May 15, 2017 8:38 AM > *To:* Ben Hilburn <bhilb...@gnuradio.org> <bhilb...@gnuradio.org> > *Cc:* discuss-gnuradio@gnu.org > *Subject:* [WARNING: SPOOFED E-MAIL--Non-Aerospace Sender] Re: > [Discuss-gnuradio] Custom C++ blocks on E310 > > > > Hi Ben, > > > > Here is some of the backtrace from the error. At the top level, the error > starts in the msg_connect function and it looks like it gets tripped up > reading something from memory when checking for a valid message port. > > > > #0 0xb635c67c in fetch_add (order=boost::memory_order_relaxed, v=1, > > storage=@0x6: <error reading variable>) > > at /home /prefix /sysroots/armv7ahf-vfp-neon- > oe-linux-gnueabi/usr/include/boost/atomic/detail/ops_gcc_atomic.hpp:100 > > #1 fetch_add (order=boost::memory_order_relaxed, v=1, this=0x6) > > at /home /prefix /sysroots/armv7ahf-vfp-neon- > oe-linux-gnueabi/usr/include/boost/atomic/detail/atomic_template.hpp:115 > > #2 pmt::intrusive_ptr_add_ref (p=0x2) > > at /home /prefix /src/gnuradio/gnuradio-runtime/lib/pmt/pmt.cc:69 > > #3 0xb63e56e4 in intrusive_ptr (rhs=..., this=0xbeffec7c) > > at /home /prefix /sysroots/armv7ahf-vfp-neon- > oe-linux-gnueabi/usr/include/boost/smart_ptr/intrusive_ptr.hpp:92 > > #4 gr::flowgraph::check_valid_port (this=this@entry=0x10c578, e=...) > > at /home /prefix /src/gnuradio/gnuradio-runtime/lib/flowgraph.cc:162 > > #5 0xb63e95d0 in gr::flowgraph::connect (this=this@entry=0x10c578, > src=..., > > dst=...) > > at /home /prefix /src/gnuradio/gnuradio-runtime/lib/flowgraph.cc:503 > > #6 0xb63f4c84 in gr::hier_block2_detail::msg_connect ( > > this=this@entry=0x10c528, src=..., srcport=..., dst=..., dstport=...) > > at /home /prefix /src/gnuradio/gnuradio-runtime/lib/hier_block2_ > detail.cc:198 > > #7 0xb63f1b14 in gr::hier_block2::msg_connect (this=this@entry=0x0, > src=..., > > srcport=..., dst=..., dstport=...) > > at /home /prefix /src/gnuradio/gnuradio-runtime/lib/hier_block2.cc:104 > > #8 0xb5cd6958 in _wrap_top_block_sptr_primitive_msg_connect__SWIG_1 ( > > args=<optimized out>) > > at /home /prefix_new/src/gnuradio/build-arm/gnuradio-runtime/ > swig/runtime_swigPYTHON_wrap.cxx:47551 > > > > Thanks, > > Jessica > > > > *From:* Ben Hilburn [mailto:bhilb...@gnuradio.org <bhilb...@gnuradio.org>] > > *Sent:* Friday, May 12, 2017 1:35 PM > *To:* Jessica Iwamoto <jessica.iwam...@aero.org> > *Cc:* discuss-gnuradio@gnu.org > *Subject:* Re: [Discuss-gnuradio] Custom C++ blocks on E310 > > > > Hey Jessica - > > > > The SIGBUS you are receiving indicates that there is likely some funniness > happening with memory addressing / access somewhere. Especially since your > test flowgraph is so simple, using GDB to get a backtrace might point you > to the offending code pretty quickly. For more details on how to do this, > check out this page on our Wiki: https://wiki.gnuradio.org/index.php/ > TutorialsDebugging#Expert_debugging_tools > > > > Have you tried this already? If so, can you share the backtrace? > > > > Cheers, > > Ben > > > > > > > > On Thu, May 11, 2017 at 6:15 PM, Jessica Iwamoto <jessica.iwam...@aero.org> > wrote: > > Hi again, > > > > Attached is the code that I’m using if anyone would like to try to > replicate my issue. The test_msg_py.py file contains the custom python > block code for a simple message sink. The test_msg_impl.cc, > test_msg_impl.h, and test_msg.h files contain the custom C++ code for a > message sink. The test.py file contains a simple flowgraph that connects a > message strobe to my custom message sink blocks. When I run test.py with > either of the blocks on my desktop, it works correctly. However, when I run > test.py after cross compiling on the E310, it works correctly with the > test_msg_py block and produces the following error with the test_msg block: > > Could not find port: in in: > > system > > Bus error > > > > Thanks, > > Jessica > > > > *From:* Discuss-gnuradio [mailto:discuss-gnuradio-bounces+jessica.iwamoto= > aero....@gnu.org] *On Behalf Of *Jessica Iwamoto > *Sent:* Wednesday, May 10, 2017 9:53 AM > *To:* discuss-gnuradio@gnu.org > *Subject:* [Discuss-gnuradio] Custom C++ blocks on E310 > > > > Hi all, > > > > I have built custom C++ blocks that work on my PC, but don’t work when > cross compiled for the E310. Specifically, I am trying to build a custom > C++ block with a message port and cross compile it for the E310. I am using > version 3.7.12 of GNU radio and the latest version of the SDK/toolchain for > the E310. I have built a simple message sink block with just a message > input port and put it in a flowgraph with a message strobe. My code runs > correctly on my PC but when I run it on the E310, I get the error: > > Could not find port: msg in: > > system > > Bus error > > > > I am able to create custom python blocks with message ports and run them > on the E310 and my PC with no issues. Additionally, I am unable to create > custom C++ blocks with normal input and output streams on the E310 (the > program seg faults when I try to connect the custom block to another > block), but they run correctly on my PC. Any suggestions on what could be > causing this? > > > > Thanks, > > Jessica > > > > > _______________________________________________ > 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
