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] *On > Behalf Of *Marcus Müller > *Sent:* Wednesday, May 24, 2017 12:26 PM > *To:* discuss-gnuradio@gnu.org; Philip Balister <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] > *On Behalf Of *Jessica Iwamoto > *Sent:* Monday, May 15, 2017 8:38 AM > *To:* Ben Hilburn <bhilb...@gnuradio.org> > <mailto:bhilb...@gnuradio.org> > *Cc:* discuss-gnuradio@gnu.org <mailto: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] > *Sent:* Friday, May 12, 2017 1:35 PM > *To:* Jessica Iwamoto <jessica.iwam...@aero.org > <mailto:jessica.iwam...@aero.org>> > *Cc:* discuss-gnuradio@gnu.org <mailto: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 <mailto: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 > <mailto:discuss-gnuradio-bounces%2Bjessica.iwamoto>=aero....@gnu.org > <mailto:aero....@gnu.org>] *On Behalf Of *Jessica Iwamoto > *Sent:* Wednesday, May 10, 2017 9:53 AM > *To:* discuss-gnuradio@gnu.org <mailto: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 <mailto:Discuss-gnuradio@gnu.org> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > > > > _______________________________________________ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org <mailto: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
