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

Reply via email to