Re: [USRP-users] Cross-compiling UHD library
Thanks--I'll give that a try when the dust clears here. On 9/4/18 1:59 PM, Martin Braun via USRP-users wrote: On Fri, Aug 17, 2018 at 01:02:28PM -0400, Daryl Lee via USRP-users wrote: In November of 2016, I cross-compiled UHD (git-cloned) on my Ubuntu 16.04 development host targeting a Zynq chip with Linux built with Petalinux 2016.3. Life has passed me by and now I need to re-build the library using the Petalinux 2017.3 toolchain. I have only a few weeks to a major milestone, with no time to adapt to all the changes that have no doubt occurred during that gap. Is there any way to use the older UHD with the newer Petalinux tools? You might be able to just remove all usage of Neon. Try removing these lines: https://github.com/EttusResearch/uhd/blob/6013a511370b9452020adfc72d7893f1c3bb2963/host/lib/convert/CMakeLists.txt#L65-L79 Of course, you'll lose the Neon assembly acceleration. Depending on your app, that might still be fast enough. -- M Here's the first of many similar errors: [ 5%] Building CXX object lib/CMakeFiles/uhd.dir/convert/convert_with_neon.cpp.o In file included from /home/daryl/RB/ZP/uhd/host/lib/convert/convert_with_neon.cpp:20:0: /home/daryl/Petalinux/2017.3/tools/linux-i386/gcc-arm-linux-gnueabi/lib/gcc/arm-linux-gnueabihf/6.2.1/include/arm_neon.h: In member function ‘virtual void __convert_fc32_1_sc16_item32_le_1_PRIORITY_SIMD::operator()(const input_type&, const output_type&, size_t)’: /home/daryl/Petalinux/2017.3/tools/linux-i386/gcc-arm-linux-gnueabi/lib/gcc/arm-linux-gnueabihf/6.2.1/include/arm_neon.h:5811:1: error: inlining failed in call to always_inline ‘float32x4_t vdupq_n_f32(float32_t)’: target specific option mismatch vdupq_n_f32 (float32_t __a) Any help will be appreciated. -- Daryl Lee Sr. Software Engineer ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com -- Daryl Lee All our discontents about what we want appeared to me to spring from the want of thankfulness for what we have. -- Daniel Defoe ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] USRP Source Block caught rx error code: 15
On 09/06/2018 04:01 PM, Harper, Andrew wrote: I'm running Xubuntu 16.04 on the hardware, i.e. not VM: Distributor ID:Ubuntu Description:Ubuntu 16.04.5 LTS Release:16.04 Codename:xenial Ethernet info: description: Ethernet interface product: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller vendor: Realtek Semiconductor Co., Ltd. physical id: 0 bus info: pci@:03:00.0 logical name: enp3s0 version: 10 serial: 68:f7:28:42:64:6b size: 1Gbit/s capacity: 1Gbit/s width: 64 bits clock: 33MHz capabilities: pm msi pciexpress msix vpd bus_master cap_list ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegotiation configuration: autonegotiation=on broadcast=yes driver=r8169 driverversion=2.3LK-NAPI duplex=full firmware=rtl8168g-3_0.0.1 04/23/13 ip=192.168.10.1 latency=0 link=yes multicast=yes port=MII speed=1Gbit/s resources: irq:27 ioport:3000(size=256) memory:f0d04000-f0d04fff memory:f0d0-f0d03fff What is the frame error count on the interface? (rx errors when using ifconfig) *From:* USRP-users on behalf of Marcus D. Leech via USRP-users *Sent:* Thursday, September 6, 2018 3:43 PM *To:* usrp-users@lists.ettus.com *Subject:* Re: [USRP-users] USRP Source Block caught rx error code: 15 On 09/06/2018 03:29 PM, Harper, Andrew via USRP-users wrote: Hi, I am having a troubling error from my x310 USRP whenever I try to pull samples using the USRP source block. The error message I am getting is: [ERROR] [STREAMER] The receive packet handler caught a value exception. ValueError: Bad CHDR or packet fragment WARN: USRP Source Block caught rx error code: 15 [ERROR] [RX FLOW CTRL] Error unpacking packet: ValueError: Bad CHDR or packet fragment The most basic flowgraph that creates this error is a USRP Source connected directly to a QT Time plot. It also happens when I try to run: 1) uhd_cal_rx_iq_balance, 2) uhd_fft, 3) uhd_cal_tx_dc_offset, My gnuradio version is 3.7.13.4, UHD version is UHD 3.14.0.0-88-g6013a511, and i have just reinstalled both to make sure it is not a software issue. I am able to successfully run uhd_find_devices and uhd_usrp_probe. I am also able to run a USRP sink block without error, if that helps identify the problem. Anyone have a fix for this? Andrew What type of Ethernet interface do you have on your system? Is this a VM, or a on-the-hardware system? Is this on Windows or Linux? ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] USRP Source Block caught rx error code: 15
On 09/06/2018 03:29 PM, Harper, Andrew via USRP-users wrote: Hi, I am having a troubling error from my x310 USRP whenever I try to pull samples using the USRP source block. The error message I am getting is: [ERROR] [STREAMER] The receive packet handler caught a value exception. ValueError: Bad CHDR or packet fragment WARN: USRP Source Block caught rx error code: 15 [ERROR] [RX FLOW CTRL] Error unpacking packet: ValueError: Bad CHDR or packet fragment The most basic flowgraph that creates this error is a USRP Source connected directly to a QT Time plot. It also happens when I try to run: 1) uhd_cal_rx_iq_balance, 2) uhd_fft, 3) uhd_cal_tx_dc_offset, My gnuradio version is 3.7.13.4, UHD version is UHD 3.14.0.0-88-g6013a511, and i have just reinstalled both to make sure it is not a software issue. I am able to successfully run uhd_find_devices and uhd_usrp_probe. I am also able to run a USRP sink block without error, if that helps identify the problem. Anyone have a fix for this? Andrew What type of Ethernet interface do you have on your system? Is this a VM, or a on-the-hardware system? Is this on Windows or Linux? ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] USRP Source Block caught rx error code: 15
Hi, I am having a troubling error from my x310 USRP whenever I try to pull samples using the USRP source block. The error message I am getting is: [ERROR] [STREAMER] The receive packet handler caught a value exception. ValueError: Bad CHDR or packet fragment WARN: USRP Source Block caught rx error code: 15 [ERROR] [RX FLOW CTRL] Error unpacking packet: ValueError: Bad CHDR or packet fragment The most basic flowgraph that creates this error is a USRP Source connected directly to a QT Time plot. It also happens when I try to run: 1) uhd_cal_rx_iq_balance, 2) uhd_fft, 3) uhd_cal_tx_dc_offset, My gnuradio version is 3.7.13.4, UHD version is UHD 3.14.0.0-88-g6013a511, and i have just reinstalled both to make sure it is not a software issue. I am able to successfully run uhd_find_devices and uhd_usrp_probe. I am also able to run a USRP sink block without error, if that helps identify the problem. Anyone have a fix for this? Andrew ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Issues installing GNUradio using PYBOMBS (e3xx-custom-uhd or e3xx-rfnoc)
On 09/06/2018 08:52 AM, Jason Matusiak wrote: > Just finished running the second command just mentioned below, still died > with the package "six" error. I found the problem, will regenerate images and sdk tonight and update Dropbox in the morning. Thanks for testing this and finding I still had an issue with the E300 sdk. Philip > > > - Original Message - Subject: RE: Re: [USRP-users] Issues > installing GNUradio using PYBOMBS (e3xx-custom-uhd or e3xx-rfnoc) > From: "Jason Matusiak" > Date: 9/6/18 8:44 am > To: "Philip Balister" > Cc: "USRP-users@lists.ettus.com" > > Thanks Philip, that will be very helpful. Will the steps be the same as > before? : > > 1 - sh ./oecore-x86_64-armv7ahf-neon-toolchain-nodistro.0.sh > 2 - pybombs prefix init /opt/gnuradio/e300 -R e3xx-rfnoc -a e300 > > Or will something need to change there? > > - Original Message - Subject: Re: [USRP-users] Issues > installing GNUradio using PYBOMBS (e3xx-custom-uhd or e3xx-rfnoc) > From: "Philip Balister" > Date: 9/5/18 3:35 pm > To: "Jason Matusiak" > Cc: "USRP-users@lists.ettus.com" > > On 09/05/2018 03:25 PM, Jason Matusiak via USRP-users wrote: > > Philip, I know I am digging this up from early in the year, but I didn't > see an answer. I am having the exact same issue with the six package. Were > you ever able to fix this? > > Pretty sure the sdk from here is fixed: > > https://www.dropbox.com/sh/4w19l8ixwm2ke24/AAB3aGPAkjqe9SvG32TsyK5Ia?dl=0 > > These are newer images based of rocko I ended creating out of another > job. Posted in case others find them useful. > > Philip > > > > > > > - Original Message - On 04/02/2018 06:58 PM, Marcus D. > Leech wrote: > > > On 04/02/2018 06:09 PM, Philip Balister wrote: > > >> On 04/02/2018 05:01 PM, MASDR GS wrote: > > >>> I'm having issues with installing GNU radio using PYBOMBS. It > > >>> successfully > > >>> installs the SDK and UHD but once it reaches to GNU Radio I receive a > > >>> missing python six message. I have been using this guide from Ettus for > > >>> reference. > > >>> > > >>> > https://kb.ettus.com/Software_Development_on_the_E310_and_E312#Preparation_using_PyBOMBS > > >>> > > >>> > > >>> > > >>> -- Python checking for six - python 2 and 3 compatibility library - not > > >>> found > > >>> CMake Error at volk/CMakeLists.txt:93 (message): > > >>> six - python 2 and 3 compatibility library required to build VOLK > > >>> > > >> Looks like the volk added a dependency on python-six and the E300 image > > >> doesn't have it. Ettus needs to create a new file system image with that > > >> package installed. > > >> > > >> Philip > > > WHile that is actually, true, in this case the user is doing > > > cross-builds on their PC host, and had installed python-six into their > > > cross-build > > > environment, and still no joy. > > > > Adding python-six-native cleared up my build issue. Likely the real > > solution is regenerate the sdk including the native-sdk version of > > python-six. > > > > I'll poke meta-sdr for this soon to cover other users. > > > > Philip > > > > > > > > > > >> > > >>> -- Configuring incomplete, errors occurred! > > >>> > > >>> > > >>> Someone also posted the same issue but I couldn't find a response to > his > > >>> question along with how to bypass this error. I've tried installing the > > >>> lastest version of python six-1.11.0 onto my local computer still but > > >>> having no luck. Any guidance or help is appreciated. > > >>> > > >>> > http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-February/023677.html > > >>> > > >>> > > >>> > > >>> > > >>> ___ > > >>> Discuss-gnuradio mailing list > > >>> address@hidden > > >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > >>> > > >> ___ > > >> Discuss-gnuradio mailing list > > >> address@hidden > > >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > > > > > > ___ > > > Discuss-gnuradio mailing list > > > address@hidden > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > > > > > > > > ___ > > USRP-users mailing list > > USRP-users@lists.ettus.com > > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] RFNOC: AXI Wrapper Configuration busses
On Thu, Sep 6, 2018 at 2:43 PM Pratik Chatterjee via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi, > > Can anyone please provide some insight on the use of configuration buses > in the axi wrapper - why and when would we want to use them? Do they > complement the axis stream signals (m_axis and s_axis) in any way? Thank > you, > I've seen them used when you need to provide tlast along with some configuration data. Specifically, I've seen it used in the FIR filter and window functions where you have reloadable coefficients that have a specific length to it, but potentially unknown. It's slow since really it's just a wrapper around the register writes that also happens to issue tlast when you write to the appropriate register. Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] RFNOC: AXI Wrapper Configuration busses
Hi, Can anyone please provide some insight on the use of configuration buses in the axi wrapper - why and when would we want to use them? Do they complement the axis stream signals (m_axis and s_axis) in any way? Thank you, Pratik ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] N310 timeout before streaming complete
Update: The issue is included on the head of the UHD-3.12 branch, but is not included in the v3.12.0.0 release. So, be sure to checkout the v3.12.0.0 tag. The issue we replicated is the STREAM_CMD_NUM_SAMPS_AND_DONE. The continuous streaming issue is still outstanding, but may be related. Regards, Michael On Thu, Sep 6, 2018 at 10:57 AM, Rob Kossler wrote: > OK. I will give it a shot. Which issue did you duplicate (the confusion > is my fault for discussing two different issues in the same thread): Issue > #1 (NUM_SAMPS_AND_DONE) or Issue #2 (CONTINUOUS)? > > Rob > > On Thu, Sep 6, 2018 at 1:52 PM Michael West > wrote: > >> Hi Rob, >> >> Thank you once again. We have reproduced the issue and are working on >> tracing down the root cause and fixing the issue. We have confirmed that >> the issue exists on 3.13, but we have also confirmed it does not exist on >> 3.12.0.0. So, you can use v3.12.0.0 in the meantime. To be sure you are >> using the correct FPGA image for v3.12.0.0, be sure to run >> 'uhd_images_downloader --refetch'. >> >> Regards, >> Michael >> >> On Tue, Sep 4, 2018 at 3:21 PM, Rob Kossler via USRP-users < >> usrp-users@lists.ettus.com> wrote: >> >>> Today, I confirmed that this issue exists on the head of 3.13 and 3.12, >>> but not 3.11. The example program provided with my previous post can be >>> compiled with any of these versions. >>> >>> Rob >>> >>> On Fri, Aug 31, 2018 at 12:33 PM Rob Kossler wrote: >>> In this post and one other post, I mentioned two issues I am having related to N310 streaming: 1. With STREAM_MODE_NUM_SAMPS_AND_DONE, sometimes I get a timeout prior to receiving the requested number of samples (this is the issue identified in this post). This may be simply dependent upon the number of samples requested. 2. With STREAM_MODE_START_CONTINUOUS, I get errors with repeated captures such that after several successful captures, I eventually get a streaming timeout and all subsequent captures fail. So, turns out that this issue is bigger for me than I realized. I had a bunch of trouble yesterday while doing some research experimentation. I had selected to go with X310 devices rather than N310 devices because of their relative maturity. Today, I confirmed that my issues yesterday with the X310 are the same as I previously mentioned for the N310 (#2 above). So, perhaps it is an issue with UHD-3.13 (I did not check any other branch). I modified the Ettus "txrx_loopback_to_file.cpp" code to include a "for loop of 50 iterations" and changed the streaming mode to be continuous. The modified source is included as an attachment (a 'diff' of my code to the original with show the minor changes I made). I attached a console log of the output messages when run with my X310 which shows both the command line parameters I used as well as the resulting errors. Note that everything is going as expected through Iteration 5, but starting at Iteration 6, there is no end-of-burst (EOB) and starting at Iteration 8, a timeout occurs prior to receiving any samples. Please let me know if you have any questions. This is a pretty big issue for me and will prevent me from using 3.13 until addressed. Rob On Fri, Aug 24, 2018 at 2:46 PM Rob Kossler wrote: > Hi, > This post is perhaps a continuation of a previous post "Problems with > MPM 3.13 on N310", but I wanted to change the subject to reflect this > current issue. > > The issue is an Rx streaming timeout. It can be easily duplicated > with a stock Ettus example. Below you will find the console log which > includes the command line parameters. Note the following: > >- I requested 31250 samples >- There is a error "Timeout while streaming" indicated at the end >- The final file size of 119340 indicates that 29835 samples were >received >- I do not have any reason to believe that the specific command >line arguments below are needed to duplicate the issue. I just didn't >bother to try other ones. > > In the other thread, I mentioned that my Rx timeout issue had gone > away after switching to streaming mode STREAM_MODE_NUM_SAMPS_AND_DONE. > However, the issue below occurs when using that mode so it will be a > problem for me. > > Let me know if you have any questions. > > Rob > > > irisheyes9@irisheyes9-Z240-SFF:/media/SSD_RAID/multi_pol$ > txrx_loopback_to_file --tx-args="addr=192.168.61.2" > --rx-args="addr=192.168.61.2" --nsamps=31250 --tx-rate=31.25e6 > --rx-rate=31.25e6 --tx-channels=0,1 --rx-channels=2,3 --tx-freq=2500e6 > --rx-freq=2500e6 > > Creating the transmit usrp device with: addr=192.168.61.2... > [INFO] [UHD] linux; GNU C++ version 5.4.0 2016
Re: [USRP-users] N310 timeout before streaming complete
OK. I will give it a shot. Which issue did you duplicate (the confusion is my fault for discussing two different issues in the same thread): Issue #1 (NUM_SAMPS_AND_DONE) or Issue #2 (CONTINUOUS)? Rob On Thu, Sep 6, 2018 at 1:52 PM Michael West wrote: > Hi Rob, > > Thank you once again. We have reproduced the issue and are working on > tracing down the root cause and fixing the issue. We have confirmed that > the issue exists on 3.13, but we have also confirmed it does not exist on > 3.12.0.0. So, you can use v3.12.0.0 in the meantime. To be sure you are > using the correct FPGA image for v3.12.0.0, be sure to run > 'uhd_images_downloader --refetch'. > > Regards, > Michael > > On Tue, Sep 4, 2018 at 3:21 PM, Rob Kossler via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> Today, I confirmed that this issue exists on the head of 3.13 and 3.12, >> but not 3.11. The example program provided with my previous post can be >> compiled with any of these versions. >> >> Rob >> >> On Fri, Aug 31, 2018 at 12:33 PM Rob Kossler wrote: >> >>> In this post and one other post, I mentioned two issues I am having >>> related to N310 streaming: >>> >>>1. With STREAM_MODE_NUM_SAMPS_AND_DONE, sometimes I get a timeout >>>prior to receiving the requested number of samples (this is the issue >>>identified in this post). This may be simply dependent upon the number of >>>samples requested. >>>2. With STREAM_MODE_START_CONTINUOUS, I get errors with repeated >>>captures such that after several successful captures, I eventually get a >>>streaming timeout and all subsequent captures fail. >>> >>> So, turns out that this issue is bigger for me than I realized. I had a >>> bunch of trouble yesterday while doing some research experimentation. I had >>> selected to go with X310 devices rather than N310 devices because of their >>> relative maturity. Today, I confirmed that my issues yesterday with the >>> X310 are the same as I previously mentioned for the N310 (#2 above). So, >>> perhaps it is an issue with UHD-3.13 (I did not check any other branch). >>> >>> I modified the Ettus "txrx_loopback_to_file.cpp" code to include a "for >>> loop of 50 iterations" and changed the streaming mode to be continuous. >>> The modified source is included as an attachment (a 'diff' of my code to >>> the original with show the minor changes I made). I attached a console log >>> of the output messages when run with my X310 which shows both the command >>> line parameters I used as well as the resulting errors. Note that >>> everything is going as expected through Iteration 5, but starting at >>> Iteration 6, there is no end-of-burst (EOB) and starting at Iteration 8, a >>> timeout occurs prior to receiving any samples. >>> >>> Please let me know if you have any questions. This is a pretty big >>> issue for me and will prevent me from using 3.13 until addressed. >>> >>> Rob >>> >>> >>> On Fri, Aug 24, 2018 at 2:46 PM Rob Kossler wrote: >>> Hi, This post is perhaps a continuation of a previous post "Problems with MPM 3.13 on N310", but I wanted to change the subject to reflect this current issue. The issue is an Rx streaming timeout. It can be easily duplicated with a stock Ettus example. Below you will find the console log which includes the command line parameters. Note the following: - I requested 31250 samples - There is a error "Timeout while streaming" indicated at the end - The final file size of 119340 indicates that 29835 samples were received - I do not have any reason to believe that the specific command line arguments below are needed to duplicate the issue. I just didn't bother to try other ones. In the other thread, I mentioned that my Rx timeout issue had gone away after switching to streaming mode STREAM_MODE_NUM_SAMPS_AND_DONE. However, the issue below occurs when using that mode so it will be a problem for me. Let me know if you have any questions. Rob irisheyes9@irisheyes9-Z240-SFF:/media/SSD_RAID/multi_pol$ txrx_loopback_to_file --tx-args="addr=192.168.61.2" --rx-args="addr=192.168.61.2" --nsamps=31250 --tx-rate=31.25e6 --rx-rate=31.25e6 --tx-channels=0,1 --rx-channels=2,3 --tx-freq=2500e6 --rx-freq=2500e6 Creating the transmit usrp device with: addr=192.168.61.2... [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_3.13.0.2-0-g0ddc19e5 [INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=192.168.61.2,type=n3xx,product=n310,serial=315A34B,claimed=False,addr=192.168.61.2 [INFO] [MPM.PeriphManager] init() called with device args `mgmt_addr=192.168.61.2,product=n310'. [INFO] [0/DmaFIFO_0] Initializing block control (NOC ID: 0xF1F0D004) [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1320 MB/s) [INFO] [0/DmaFI
Re: [USRP-users] N310 timeout before streaming complete
Hi Rob, Thank you once again. We have reproduced the issue and are working on tracing down the root cause and fixing the issue. We have confirmed that the issue exists on 3.13, but we have also confirmed it does not exist on 3.12.0.0. So, you can use v3.12.0.0 in the meantime. To be sure you are using the correct FPGA image for v3.12.0.0, be sure to run 'uhd_images_downloader --refetch'. Regards, Michael On Tue, Sep 4, 2018 at 3:21 PM, Rob Kossler via USRP-users < usrp-users@lists.ettus.com> wrote: > Today, I confirmed that this issue exists on the head of 3.13 and 3.12, > but not 3.11. The example program provided with my previous post can be > compiled with any of these versions. > > Rob > > On Fri, Aug 31, 2018 at 12:33 PM Rob Kossler wrote: > >> In this post and one other post, I mentioned two issues I am having >> related to N310 streaming: >> >>1. With STREAM_MODE_NUM_SAMPS_AND_DONE, sometimes I get a timeout >>prior to receiving the requested number of samples (this is the issue >>identified in this post). This may be simply dependent upon the number of >>samples requested. >>2. With STREAM_MODE_START_CONTINUOUS, I get errors with repeated >>captures such that after several successful captures, I eventually get a >>streaming timeout and all subsequent captures fail. >> >> So, turns out that this issue is bigger for me than I realized. I had a >> bunch of trouble yesterday while doing some research experimentation. I had >> selected to go with X310 devices rather than N310 devices because of their >> relative maturity. Today, I confirmed that my issues yesterday with the >> X310 are the same as I previously mentioned for the N310 (#2 above). So, >> perhaps it is an issue with UHD-3.13 (I did not check any other branch). >> >> I modified the Ettus "txrx_loopback_to_file.cpp" code to include a "for >> loop of 50 iterations" and changed the streaming mode to be continuous. >> The modified source is included as an attachment (a 'diff' of my code to >> the original with show the minor changes I made). I attached a console log >> of the output messages when run with my X310 which shows both the command >> line parameters I used as well as the resulting errors. Note that >> everything is going as expected through Iteration 5, but starting at >> Iteration 6, there is no end-of-burst (EOB) and starting at Iteration 8, a >> timeout occurs prior to receiving any samples. >> >> Please let me know if you have any questions. This is a pretty big issue >> for me and will prevent me from using 3.13 until addressed. >> >> Rob >> >> >> On Fri, Aug 24, 2018 at 2:46 PM Rob Kossler wrote: >> >>> Hi, >>> This post is perhaps a continuation of a previous post "Problems with >>> MPM 3.13 on N310", but I wanted to change the subject to reflect this >>> current issue. >>> >>> The issue is an Rx streaming timeout. It can be easily duplicated with >>> a stock Ettus example. Below you will find the console log which includes >>> the command line parameters. Note the following: >>> >>>- I requested 31250 samples >>>- There is a error "Timeout while streaming" indicated at the end >>>- The final file size of 119340 indicates that 29835 samples were >>>received >>>- I do not have any reason to believe that the specific command line >>>arguments below are needed to duplicate the issue. I just didn't bother >>> to >>>try other ones. >>> >>> In the other thread, I mentioned that my Rx timeout issue had gone away >>> after switching to streaming mode STREAM_MODE_NUM_SAMPS_AND_DONE. >>> However, the issue below occurs when using that mode so it will be a >>> problem for me. >>> >>> Let me know if you have any questions. >>> >>> Rob >>> >>> >>> irisheyes9@irisheyes9-Z240-SFF:/media/SSD_RAID/multi_pol$ >>> txrx_loopback_to_file --tx-args="addr=192.168.61.2" >>> --rx-args="addr=192.168.61.2" --nsamps=31250 --tx-rate=31.25e6 >>> --rx-rate=31.25e6 --tx-channels=0,1 --rx-channels=2,3 --tx-freq=2500e6 >>> --rx-freq=2500e6 >>> >>> Creating the transmit usrp device with: addr=192.168.61.2... >>> [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800; >>> UHD_3.13.0.2-0-g0ddc19e5 >>> [INFO] [MPMD] Initializing 1 device(s) in parallel with args: >>> mgmt_addr=192.168.61.2,type=n3xx,product=n310,serial= >>> 315A34B,claimed=False,addr=192.168.61.2 >>> [INFO] [MPM.PeriphManager] init() called with device args >>> `mgmt_addr=192.168.61.2,product=n310'. >>> [INFO] [0/DmaFIFO_0] Initializing block control (NOC ID: >>> 0xF1F0D004) >>> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1320 MB/s) >>> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1336 MB/s) >>> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1331 MB/s) >>> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1349 MB/s) >>> [INFO] [0/Radio_0] Initializing block control (NOC ID: >>> 0x12AD10011312) >>> [INFO] [0/Radio_1] Initializing block control (NOC ID: >>> 0x12AD10011312) >>> [INFO] [0/DDC_0] Initia
Re: [USRP-users] Issues installing GNUradio using PYBOMBS (e3xx-custom-uhd or e3xx-rfnoc)
On 09/06/2018 08:52 AM, Jason Matusiak wrote: > Just finished running the second command just mentioned below, still died > with the package "six" error. I looked at the sdk manifest in Dropbox and don't see the python-six included, but it looks like the sdk should. Going to run some builds here, maybe just a matter of updating Dropbox from the output of the Jenkins job doing test builds. Philip > > > - Original Message - Subject: RE: Re: [USRP-users] Issues > installing GNUradio using PYBOMBS (e3xx-custom-uhd or e3xx-rfnoc) > From: "Jason Matusiak" > Date: 9/6/18 8:44 am > To: "Philip Balister" > Cc: "USRP-users@lists.ettus.com" > > Thanks Philip, that will be very helpful. Will the steps be the same as > before? : > > 1 - sh ./oecore-x86_64-armv7ahf-neon-toolchain-nodistro.0.sh > 2 - pybombs prefix init /opt/gnuradio/e300 -R e3xx-rfnoc -a e300 > > Or will something need to change there? > > - Original Message - Subject: Re: [USRP-users] Issues > installing GNUradio using PYBOMBS (e3xx-custom-uhd or e3xx-rfnoc) > From: "Philip Balister" > Date: 9/5/18 3:35 pm > To: "Jason Matusiak" > Cc: "USRP-users@lists.ettus.com" > > On 09/05/2018 03:25 PM, Jason Matusiak via USRP-users wrote: > > Philip, I know I am digging this up from early in the year, but I didn't > see an answer. I am having the exact same issue with the six package. Were > you ever able to fix this? > > Pretty sure the sdk from here is fixed: > > https://www.dropbox.com/sh/4w19l8ixwm2ke24/AAB3aGPAkjqe9SvG32TsyK5Ia?dl=0 > > These are newer images based of rocko I ended creating out of another > job. Posted in case others find them useful. > > Philip > > > > > > > - Original Message - On 04/02/2018 06:58 PM, Marcus D. > Leech wrote: > > > On 04/02/2018 06:09 PM, Philip Balister wrote: > > >> On 04/02/2018 05:01 PM, MASDR GS wrote: > > >>> I'm having issues with installing GNU radio using PYBOMBS. It > > >>> successfully > > >>> installs the SDK and UHD but once it reaches to GNU Radio I receive a > > >>> missing python six message. I have been using this guide from Ettus for > > >>> reference. > > >>> > > >>> > https://kb.ettus.com/Software_Development_on_the_E310_and_E312#Preparation_using_PyBOMBS > > >>> > > >>> > > >>> > > >>> -- Python checking for six - python 2 and 3 compatibility library - not > > >>> found > > >>> CMake Error at volk/CMakeLists.txt:93 (message): > > >>> six - python 2 and 3 compatibility library required to build VOLK > > >>> > > >> Looks like the volk added a dependency on python-six and the E300 image > > >> doesn't have it. Ettus needs to create a new file system image with that > > >> package installed. > > >> > > >> Philip > > > WHile that is actually, true, in this case the user is doing > > > cross-builds on their PC host, and had installed python-six into their > > > cross-build > > > environment, and still no joy. > > > > Adding python-six-native cleared up my build issue. Likely the real > > solution is regenerate the sdk including the native-sdk version of > > python-six. > > > > I'll poke meta-sdr for this soon to cover other users. > > > > Philip > > > > > > > > > > >> > > >>> -- Configuring incomplete, errors occurred! > > >>> > > >>> > > >>> Someone also posted the same issue but I couldn't find a response to > his > > >>> question along with how to bypass this error. I've tried installing the > > >>> lastest version of python six-1.11.0 onto my local computer still but > > >>> having no luck. Any guidance or help is appreciated. > > >>> > > >>> > http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-February/023677.html > > >>> > > >>> > > >>> > > >>> > > >>> ___ > > >>> Discuss-gnuradio mailing list > > >>> address@hidden > > >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > >>> > > >> ___ > > >> Discuss-gnuradio mailing list > > >> address@hidden > > >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > > > > > > ___ > > > Discuss-gnuradio mailing list > > > address@hidden > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > > > > > > > > ___ > > USRP-users mailing list > > USRP-users@lists.ettus.com > > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Issues installing GNUradio using PYBOMBS (e3xx-custom-uhd or e3xx-rfnoc)
Sorry Andrew, I didn't see your response.
I tried your steps, but on the gnuradio rebuild, it failes with this error:
[ 6%] Building CXX object
gnuradio-runtime/lib/CMakeFiles/gnuradio-runtime.dir/block.cc.o
/opt/gnuradio/e300/src/gnuradio/gnuradio-runtime/lib/block.cc: In member
function 'void gr::block::set_relative_rate(uint64_t, uint64_t)':
/opt/gnuradio/e300/src/gnuradio/gnuradio-runtime/lib/block.cc:203:61: error:
conversion from 'uint64_t {aka long long unsigned int}' to 'const mpz_class
{aka const __gmp_expr<__mpz_struct [1], __mpz_struct [1]>}' is ambiguous
d_mp_relative_rate = mpq_class(interpolation, decimation);
^
/opt/gnuradio/e300/src/gnuradio/gnuradio-runtime/lib/block.cc:195:37: note:
candidates are:
block::set_relative_rate(uint64_t interpolation, uint64_t decimation)
^
In file included from
/opt/gnuradio/e300/src/gnuradio/gnuradio-runtime/include/gnuradio/block.h:34:0,
from /opt/gnuradio/e300/src/gnuradio/gnuradio-runtime/lib/block.cc:27:
/opt/gnuradio/e300/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/include/gmpxx.h:1442:12:
note: __gmp_expr<__mpz_struct [1], __mpz_struct [1]>::__gmp_expr(mpz_srcptr)
explicit __gmp_expr(mpz_srcptr z) { mpz_init_set(mp, z); }
^
/opt/gnuradio/e300/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/include/gmpxx.h:1442:12:
note: no known conversion for argument 1 from 'uint64_t {aka long long
unsigned int}' to 'mpz_srcptr {aka const __mpz_struct*}'
/opt/gnuradio/e300/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/include/gmpxx.h:1425:12:
note: __gmp_expr<__mpz_struct [1], __mpz_struct [1]>::__gmp_expr(const char*,
int)
explicit __gmp_expr(const char *s, int base = 0)
^
/opt/gnuradio/e300/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/include/gmpxx.h:1425:12:
note: no known conversion for argument 1 from 'uint64_t {aka long long
unsigned int}' to 'const char*'
/opt/gnuradio/e300/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/include/gmpxx.h:1423:3:
note: __gmp_expr<__mpz_struct [1], __mpz_struct [1]>::__gmp_expr(double)
__GMPXX_DEFINE_ARITHMETIC_CONSTRUCTORS
^
/opt/gnuradio/e300/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/include/gmpxx.h:1423:3:
note: __gmp_expr<__mpz_struct [1], __mpz_struct [1]>::__gmp_expr(float)
__GMPXX_DEFINE_ARITHMETIC_CONSTRUCTORS
^
/opt/gnuradio/e300/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/include/gmpxx.h:1423:3:
note: __gmp_expr<__mpz_struct [1], __mpz_struct [1]>::__gmp_expr(long unsigned
int)
__GMPXX_DEFINE_ARITHMETIC_CONSTRUCTORS
^
/opt/gnuradio/e300/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/include/gmpxx.h:1423:3:
note: __gmp_expr<__mpz_struct [1], __mpz_struct [1]>::__gmp_expr(long int)
__GMPXX_DEFINE_ARITHMETIC_CONSTRUCTORS
^
/opt/gnuradio/e300/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/include/gmpxx.h:1423:3:
note: __gmp_expr<__mpz_struct [1], __mpz_struct [1]>::__gmp_expr(short
unsigned int)
__GMPXX_DEFINE_ARITHMETIC_CONSTRUCTORS
^
/opt/gnuradio/e300/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/include/gmpxx.h:1423:3:
note: __gmp_expr<__mpz_struct [1], __mpz_struct [1]>::__gmp_expr(short int)
__GMPXX_DEFINE_ARITHMETIC_CONSTRUCTORS
^
/opt/gnuradio/e300/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/include/gmpxx.h:1423:3:
note: __gmp_expr<__mpz_struct [1], __mpz_struct [1]>::__gmp_expr(unsigned int)
__GMPXX_DEFINE_ARITHMETIC_CONSTRUCTORS
^
/opt/gnuradio/e300/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/include/gmpxx.h:1423:3:
note: __gmp_expr<__mpz_struct [1], __mpz_struct [1]>::__gmp_expr(int)
__GMPXX_DEFINE_ARITHMETIC_CONSTRUCTORS
^
/opt/gnuradio/e300/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/include/gmpxx.h:1423:3:
note: __gmp_expr<__mpz_struct [1], __mpz_struct [1]>::__gmp_expr(unsigned char)
__GMPXX_DEFINE_ARITHMETIC_CONSTRUCTORS
^
/opt/gnuradio/e300/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/include/gmpxx.h:1423:3:
note: __gmp_expr<__mpz_struct [1], __mpz_struct [1]>::__gmp_expr(signed char)
__GMPXX_DEFINE_ARITHMETIC_CONSTRUCTORS
^
/opt/gnuradio/e300/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/include/gmpxx.h:1615:3:
note: initializing argument 1 of '__gmp_expr<__mpq_struct [1], __mpq_struct
[1]>::__gmp_expr(const mpz_class&, const mpz_class&)'
__gmp_expr(const mpz_class &num, const mpz_class &den)
^
make[2]: *** [gnuradio-runtime/lib/CMakeFiles/gnuradio-runtime.dir/block.cc.o]
Error 1
make[1]: *** [gnuradio-runtime/lib/CMakeFiles/gnuradio-runtime.dir/all] Error 2
make: *** [all] Error 2
PyBOMBS.Packager.source - ERROR - Build failed. See output above for error
messages.
PyBOMBS.Packager.source - ERROR - Problem occurred while building package
gnuradio:
PyBOMBS.Packager.source - ERROR - Build failed.
PyBOMBS.rebuild - ERROR - Error rebuilding package gnuradio. Aborting.
Now, this could be because I am using Philip's new image from yesterday, but I
wanted it out here for prosperity's sake.
- Original Message - Subject: Re: [USRP-users] Issues
installing GNUradio using PYBOMBS (e3xx
Re: [USRP-users] Issues installing GNUradio using PYBOMBS (e3xx-custom-uhd or e3xx-rfnoc)
Just finished running the second command just mentioned below, still died with the package "six" error. - Original Message - Subject: RE: Re: [USRP-users] Issues installing GNUradio using PYBOMBS (e3xx-custom-uhd or e3xx-rfnoc) From: "Jason Matusiak" Date: 9/6/18 8:44 am To: "Philip Balister" Cc: "USRP-users@lists.ettus.com" Thanks Philip, that will be very helpful. Will the steps be the same as before? : 1 - sh ./oecore-x86_64-armv7ahf-neon-toolchain-nodistro.0.sh 2 - pybombs prefix init /opt/gnuradio/e300 -R e3xx-rfnoc -a e300 Or will something need to change there? - Original Message - Subject: Re: [USRP-users] Issues installing GNUradio using PYBOMBS (e3xx-custom-uhd or e3xx-rfnoc) From: "Philip Balister" Date: 9/5/18 3:35 pm To: "Jason Matusiak" Cc: "USRP-users@lists.ettus.com" On 09/05/2018 03:25 PM, Jason Matusiak via USRP-users wrote: > Philip, I know I am digging this up from early in the year, but I didn't see > an answer. I am having the exact same issue with the six package. Were you > ever able to fix this? Pretty sure the sdk from here is fixed: https://www.dropbox.com/sh/4w19l8ixwm2ke24/AAB3aGPAkjqe9SvG32TsyK5Ia?dl=0 These are newer images based of rocko I ended creating out of another job. Posted in case others find them useful. Philip > > > - Original Message - On 04/02/2018 06:58 PM, Marcus D. Leech > wrote: > > On 04/02/2018 06:09 PM, Philip Balister wrote: > >> On 04/02/2018 05:01 PM, MASDR GS wrote: > >>> I'm having issues with installing GNU radio using PYBOMBS. It > >>> successfully > >>> installs the SDK and UHD but once it reaches to GNU Radio I receive a > >>> missing python six message. I have been using this guide from Ettus for > >>> reference. > >>> > >>> https://kb.ettus.com/Software_Development_on_the_E310_and_E312#Preparation_using_PyBOMBS > >>> > >>> > >>> > >>> -- Python checking for six - python 2 and 3 compatibility library - not > >>> found > >>> CMake Error at volk/CMakeLists.txt:93 (message): > >>> six - python 2 and 3 compatibility library required to build VOLK > >>> > >> Looks like the volk added a dependency on python-six and the E300 image > >> doesn't have it. Ettus needs to create a new file system image with that > >> package installed. > >> > >> Philip > > WHile that is actually, true, in this case the user is doing > > cross-builds on their PC host, and had installed python-six into their > > cross-build > > environment, and still no joy. > > Adding python-six-native cleared up my build issue. Likely the real > solution is regenerate the sdk including the native-sdk version of > python-six. > > I'll poke meta-sdr for this soon to cover other users. > > Philip > > > > > > >> > >>> -- Configuring incomplete, errors occurred! > >>> > >>> > >>> Someone also posted the same issue but I couldn't find a response to his > >>> question along with how to bypass this error. I've tried installing the > >>> lastest version of python six-1.11.0 onto my local computer still but > >>> having no luck. Any guidance or help is appreciated. > >>> > >>> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-February/023677.html > >>> > >>> > >>> > >>> > >>> ___ > >>> Discuss-gnuradio mailing list > >>> address@hidden > >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >>> > >> ___ > >> Discuss-gnuradio mailing list > >> address@hidden > >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > > > ___ > > Discuss-gnuradio mailing list > > address@hidden > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > > > ___ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Issues installing GNUradio using PYBOMBS (e3xx-custom-uhd or e3xx-rfnoc)
Thanks Philip, that will be very helpful. Will the steps be the same as before? : 1 - sh ./oecore-x86_64-armv7ahf-neon-toolchain-nodistro.0.sh 2 - pybombs prefix init /opt/gnuradio/e300 -R e3xx-rfnoc -a e300 Or will something need to change there? - Original Message - Subject: Re: [USRP-users] Issues installing GNUradio using PYBOMBS (e3xx-custom-uhd or e3xx-rfnoc) From: "Philip Balister" Date: 9/5/18 3:35 pm To: "Jason Matusiak" Cc: "USRP-users@lists.ettus.com" On 09/05/2018 03:25 PM, Jason Matusiak via USRP-users wrote: > Philip, I know I am digging this up from early in the year, but I didn't see > an answer. I am having the exact same issue with the six package. Were you > ever able to fix this? Pretty sure the sdk from here is fixed: https://www.dropbox.com/sh/4w19l8ixwm2ke24/AAB3aGPAkjqe9SvG32TsyK5Ia?dl=0 These are newer images based of rocko I ended creating out of another job. Posted in case others find them useful. Philip > > > - Original Message - On 04/02/2018 06:58 PM, Marcus D. Leech > wrote: > > On 04/02/2018 06:09 PM, Philip Balister wrote: > >> On 04/02/2018 05:01 PM, MASDR GS wrote: > >>> I'm having issues with installing GNU radio using PYBOMBS. It > >>> successfully > >>> installs the SDK and UHD but once it reaches to GNU Radio I receive a > >>> missing python six message. I have been using this guide from Ettus for > >>> reference. > >>> > >>> https://kb.ettus.com/Software_Development_on_the_E310_and_E312#Preparation_using_PyBOMBS > >>> > >>> > >>> > >>> -- Python checking for six - python 2 and 3 compatibility library - not > >>> found > >>> CMake Error at volk/CMakeLists.txt:93 (message): > >>> six - python 2 and 3 compatibility library required to build VOLK > >>> > >> Looks like the volk added a dependency on python-six and the E300 image > >> doesn't have it. Ettus needs to create a new file system image with that > >> package installed. > >> > >> Philip > > WHile that is actually, true, in this case the user is doing > > cross-builds on their PC host, and had installed python-six into their > > cross-build > > environment, and still no joy. > > Adding python-six-native cleared up my build issue. Likely the real > solution is regenerate the sdk including the native-sdk version of > python-six. > > I'll poke meta-sdr for this soon to cover other users. > > Philip > > > > > > >> > >>> -- Configuring incomplete, errors occurred! > >>> > >>> > >>> Someone also posted the same issue but I couldn't find a response to his > >>> question along with how to bypass this error. I've tried installing the > >>> lastest version of python six-1.11.0 onto my local computer still but > >>> having no luck. Any guidance or help is appreciated. > >>> > >>> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-February/023677.html > >>> > >>> > >>> > >>> > >>> ___ > >>> Discuss-gnuradio mailing list > >>> address@hidden > >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >>> > >> ___ > >> Discuss-gnuradio mailing list > >> address@hidden > >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > > > ___ > > Discuss-gnuradio mailing list > > address@hidden > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > > > ___ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
