[USRP-users] B210 drops one sample every 2^32 samples !
While analyzing GPS timing capabilities of gnss-sdr as described at https://github.com/gnss-sdr/gnss-sdr/issues/442 we have become convinced that the B210 transferring data using libuhd 3.15 drops one samples every 2^32 (i.e one sample every 4294967296). This conclusion was reached by changing the sampling rate and observing that the time shift in the GPS timing capability was jumping by one sample period every 4294967296 acquisitions (i.e. 36 minutes at 2 MS/s or 57 minutes at 1.25 MS/s). This issue is NOT observed with an X310 streaming data to the same libuhd source. We have no idea how to address or solve the problem, but any hint at how to correct the issue would be welcome. Thank you, Jean-Michel [1] running on a Raspberry Pi4 with a 64-bit kernel and 64-bit libraries/toolchain compiled with Buildroot -- JM Friedt, FEMTO-ST Time & Frequency, 26 rue de l'Epitaphe, 25000 Besancon, France ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] RFNoC Fosphor error
Hi Jonathon, I've reduced both with no change. Ben On Wed, Nov 4, 2020 at 1:59 PM Jonathon Pendlum wrote: > Hi Robert, > > Try using the maximum MTU size supported. Also, try reducing the FFT size > and SPP to 512. > > Jonathon > > On Wed, Nov 4, 2020 at 8:45 AM Robert Wilson > wrote: > >> My Ethernet Controller is a Qualcomm Atheros AR8151 it’s max MTU is 6144 >> bytes. I’ve changed MTU to the max with no change in gnuRadio response. Is >> the 6144 bytes not enough? >> >> On Tue, Nov 3, 2020 at 9:32 PM Jonathon Pendlum < >> jonathon.pend...@ettus.com> wrote: >> >>> Hi Ben, >>> >>> Try setting your NIC's MTU to 9000. >>> >>> Jonathon >>> >>> On Mon, Nov 2, 2020 at 6:55 AM Robert Wilson via USRP-users < >>> usrp-users@lists.ettus.com> wrote: >>> Hello, OS: Linux Ubuntu 20.04.1 LTS GRC: 3.8 UHD: 4.0 USRP:X310 (HG) I have been looking at RFNoC only for a few weeks. I have followed the RFNoC Workshop 4 tutorial and successfully built my own custom gain block as well as implemented and FFT from existing blocks using the "Getting Started with RFNoC" document online. I am now attempting to get Fosphor up and running on my X310 to further understand bitstream generation from YAML files. At one point I believe there was an example bitstream that had the correct Fosphor configuration I don't see it in the build of UHD I have. I've attached my .yml file and a copy of my GRC flow graph. Below is the error message I'm receiving. [INFO] [UHD] linux; GNU C++ version 9.3.0; Boost_107100; UHD_4.0.0.0-1-gcf570707 [INFO] [X300] X300 initialization sequence... [INFO] [X300] Maximum frame size: 1472 bytes. [INFO] [GPS] No GPSDO found [INFO] [X300] Radio 1x clock: 200 MHz [WARNING] [RFNOC::BLOCK_FACTORY] Could not find block with Noc-ID 0xfd7d809a, 0x [WARNING] [0/Radio#0] Setting RX IQ Balance is not possible on this device. gr::log :DEBUG: rfnoc_rx_streamer0 - Committing graph... [WARNING] [0/Radio#0] Attempting to set tick rate to 0. Skipping. gr::log :DEBUG: rfnoc_rx_streamer1 - Committing graph... gr::log :DEBUG: rfnoc_rx_streamer1 - Sending start stream command... gr::log :DEBUG: rfnoc_rx_streamer0 - Sending start stream command... >>> Done (return code -11) More resources of this type of development would be welcome as well. Many Thanks, Ben Wilson ___ 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] B210 drops one sample every 2^32 samples !
Do you see the same thing on other platforms? What about newer/older UHD versions? Sent from my iPhone > On Nov 6, 2020, at 5:29 AM, JM Friedt via USRP-users > wrote: > > While analyzing GPS timing capabilities of gnss-sdr as described at > https://github.com/gnss-sdr/gnss-sdr/issues/442 > we have become convinced that the B210 transferring data using libuhd 3.15 > drops one samples every 2^32 (i.e one sample every 4294967296). This > conclusion > was reached by changing the sampling rate and observing that the time shift > in > the GPS timing capability was jumping by one sample period every 4294967296 > acquisitions (i.e. 36 minutes at 2 MS/s or 57 minutes at 1.25 MS/s). This > issue > is NOT observed with an X310 streaming data to the same libuhd source. > We have no idea how to address or solve the problem, but any hint at how to > correct > the issue would be welcome. > > Thank you, Jean-Michel > > [1] running on a Raspberry Pi4 with a 64-bit kernel and 64-bit > libraries/toolchain compiled > with Buildroot > > -- > JM Friedt, FEMTO-ST Time & Frequency, 26 rue de l'Epitaphe, 25000 Besancon, > France > > ___ > 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] B210 drops one sample every 2^32 samples !
I was waiting to confirm measurements: * I confirm libuhd 3.15 running the X310 will NOT display the same effect * I confirm libuhd 4 DOES display the same effect on the B210. I can provide the charts which I did not upload on the gnss-sdr github issue as demonstration of these measurements. Thanks, JM -- JM Friedt, FEMTO-ST Time & Frequency, 26 rue de l'Epitaphe, 25000 Besancon, France November 6, 2020 7:18 PM, "Marcus D Leech" wrote: > Do you see the same thing on other platforms? What about newer/older UHD > versions? > > Sent from my iPhone > >> On Nov 6, 2020, at 5:29 AM, JM Friedt via USRP-users >> wrote: >> >> While analyzing GPS timing capabilities of gnss-sdr as described at >> https://github.com/gnss-sdr/gnss-sdr/issues/442 >> we have become convinced that the B210 transferring data using libuhd 3.15 >> drops one samples every 2^32 (i.e one sample every 4294967296). This >> conclusion >> was reached by changing the sampling rate and observing that the time shift >> in >> the GPS timing capability was jumping by one sample period every 4294967296 >> acquisitions (i.e. 36 minutes at 2 MS/s or 57 minutes at 1.25 MS/s). This >> issue >> is NOT observed with an X310 streaming data to the same libuhd source. >> We have no idea how to address or solve the problem, but any hint at how to >> correct >> the issue would be welcome. >> >> Thank you, Jean-Michel >> >> [1] running on a Raspberry Pi4 with a 64-bit kernel and 64-bit >> libraries/toolchain compiled >> with Buildroot >> >> -- >> JM Friedt, FEMTO-ST Time & Frequency, 26 rue de l'Epitaphe, 25000 Besancon, >> France >> >> ___ >> 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] B210 drops one sample every 2^32 samples !
Thanks, Jean-Michel. Sent from my iPhone > On Nov 6, 2020, at 1:24 PM, jeanmichel.fri...@femto-st.fr wrote: > > I was waiting to confirm measurements: > * I confirm libuhd 3.15 running the X310 will NOT display the same effect > * I confirm libuhd 4 DOES display the same effect on the B210. > > I can provide the charts which I did not upload on the gnss-sdr github issue > as demonstration of these measurements. > > Thanks, JM > > -- > JM Friedt, FEMTO-ST Time & Frequency, 26 rue de l'Epitaphe, 25000 Besancon, > France > > November 6, 2020 7:18 PM, "Marcus D Leech" wrote: > >> Do you see the same thing on other platforms? What about newer/older UHD >> versions? >> >> Sent from my iPhone >> On Nov 6, 2020, at 5:29 AM, JM Friedt via USRP-users wrote: >>> >>> While analyzing GPS timing capabilities of gnss-sdr as described at >>> https://github.com/gnss-sdr/gnss-sdr/issues/442 >>> we have become convinced that the B210 transferring data using libuhd 3.15 >>> drops one samples every 2^32 (i.e one sample every 4294967296). This >>> conclusion >>> was reached by changing the sampling rate and observing that the time shift >>> in >>> the GPS timing capability was jumping by one sample period every 4294967296 >>> acquisitions (i.e. 36 minutes at 2 MS/s or 57 minutes at 1.25 MS/s). This >>> issue >>> is NOT observed with an X310 streaming data to the same libuhd source. >>> We have no idea how to address or solve the problem, but any hint at how to >>> correct >>> the issue would be welcome. >>> >>> Thank you, Jean-Michel >>> >>> [1] running on a Raspberry Pi4 with a 64-bit kernel and 64-bit >>> libraries/toolchain compiled >>> with Buildroot >>> >>> -- >>> JM Friedt, FEMTO-ST Time & Frequency, 26 rue de l'Epitaphe, 25000 Besancon, >>> France >>> >>> ___ >>> 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
[USRP-users] E310 FPGA Development
Hi all - just joined today as I have recently started using the E310. My goal is to get a customized FPGA build running on the E310. Using the various application notes on the Ettus site I have been able to install (manually with source) UHD, GNU Radio, gr-ettus. I've also downloaded the SDK and cross-compiled each for the E310. I've been able to flash a SD image to a 32G SD card and then copy the newly compiled development environment over to the E310. I've been able to verify gnuradio operation by implementing the simple FM receiver that runs both on the embedded device and on the host. For the FPGA environment I used pybombs to install the rfnoc recipe. I modified the rfnoc recipe as follows: (thinking that I need to ensure FPGA is at 3.15 level which is what I manually cross-compiled the UHD with) config: packages: uhd: gitbranch: UHD-3.15.LTS forcebuild: True vars: config_opt: " -DENABLE_RFNOC=ON " gnuradio: gitbranch: maint-3.7 forcebuild: True gr-ettus: gitbranch: maint-3.7 forcebuild: True uhd-fpga: gitbranch: UHD-3.15.LTS I also have Xilinx, Vivado 2018.3. I've been stepping through the AN-823 (getting started with RFNOC). Before getting into the more complex development with rfnocmodtool, I started with simply creating a new FPGA file with existing RFNOC modules. I ran the script: "./uhd_image_builder.py window fft -d e310 -t E310 -m 5 --fill-with-fifos" and successfully got the output files (usrp_e310_sg1_fpga.bit/dts/rpt). I then copied the output files onto the E310 device into ~/fpga_bit. This is where I started to run into problems. First, I verified that I was using the newly installed version of UHD. I ran "which uhd_usrp_probe" to verify "/data/localinstall/usr/bin/uhd_usrp_probe". I also checked the version: root@ni-e31x:/data/localinstall/usr/share/uhd/images# uhd_usrp_probe --version 3.15.0.HEAD-0-gaea0e2de Then I ran "uhd_image_loader --args type=e3xx --fpga-path ~/fpga_bit/usrp_e310_sg1_fpga.bit"root@ni-e31x:/data/localinstall/usr/share/uhd/images# uhd_image_loader --args type=e3xx --fpga-path ~/fpga_bit/usrp_e310_sg1_fpga.bit With the following output: [INFO] [UHD] linux; GNU C++ version 8.2.0; Boost_106800; UHD_3.15.0.HEAD-0-gaea0e2de [INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=127.0.0.1,type=e3xx,product=e310_sg1,serial=3092E3A,claimed=False,skip_init=1 [INFO] [MPM.PeriphManager] Found 1 daughterboard(s). [INFO] [MPMD] Claimed device without full initialization. [INFO] [MPMD IMAGE LOADER] Starting update. This may take a while. [INFO] [MPM.PeriphManager] Updating component `fpga' [INFO] [MPM.PeriphManager] Updating component `dts' [INFO] [MPM.RPCServer] Resetting peripheral manager. [WARNING] [MPM.PeriphManager] Skipping HW/SW compatibility check! [INFO] [MPM.PeriphManager] Device serial number: 3092E3A [INFO] [MPMD IMAGE LOADER] Update component function succeeded. [WARNING] [MPM.GPSDIface] Could not connect to GPSd! None of the GPS sensors will work! root@ni-e31x:/data/localinstall/usr/share/uhd/images# Then run "uhd_usrp_probe" gives: root@ni-e31x:/data/localinstall/usr/share/uhd/images# uhd_usrp_probe [INFO] [UHD] linux; GNU C++ version 8.2.0; Boost_106800; UHD_3.15.0.HEAD-0-gaea0e2de [INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=127.0.0.1,type=e3xx,product=e310_sg1,serial=3092E3A,claimed=False [WARNING] [MPM.PeriphManager] Cannot run deinit(), device was never fully initialized! [INFO] [MPM.PeriphManager] Found 1 daughterboard(s). [ERROR] [MPM.PeriphManager] Major compat number mismatch for component `FPGA': Expected: 1.0 Actual: 5.0 [ERROR] [MPM.PeriphManager] Failed to initialize motherboard: Major compat number mismatch for component `FPGA': Expected: 1.0 Actual: 5.0 Error: RuntimeError: Device is in bad state: Major compat number mismatch for component `FPGA': Expected: 1.0 Actual: 5.0 root@ni-e31x:/data/localinstall/usr/share/uhd/images# So, a major compat mismatch seems like I'm using the wrong FPGA version with the UHD version. But I think I have UHD-3.15.LTS for both UHD and FPGA. Something is wrong between what I'm using for the FPGA files and what I'm using for the UHD. I seem to be close but thought I would ask for a little input to help get me straightened out. Thanks for any assistance. Mike ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] N320 inverted spectrum when tuned below 450 MHz
R&D did some testing and indeed at least in UHD 4.0 the spectrum is inverted. Hopefully a fix will be available soon now that it is confirmed. Sent from my iPhone > On Nov 3, 2020, at 3:27 PM, Marcus D. Leech wrote: > > On 11/03/2020 02:54 PM, Jason Roehm via USRP-users wrote: >> >>> On 10/14/20 2:41 PM, Marcus D. Leech via USRP-users wrote: >>> On 10/14/2020 01:28 PM, Jason Roehm via USRP-users wrote: I have an N320 that I'm trying out for the first time. I'm using UHD 4.0.0, and I loaded the corresponding root filesystem data for that release to the N320. I find that when the receiver is tuned to frequencies below 450 MHz, the spectrum is inverted. When you tune to 450 MHz or above, the spectrum is upright as expected. See the attached screenshots for example spectral plots. There are several ATSC signals visible in the spectrum. I simply used an indoor antenna, so there is a lot of multipath on the signals causing their spectra to be very non-flat, but the telltale sign of spectral inversion here is where the pilot tone is appearing on each one. In the first plot, tuned to 440 MHz, they appear on the right of each signal; this is not where they should be. When you tune to 450 MHz, the location of the signals flip to the right half of the plot, and the pilot tone is on the left, where they belong. Is this a known issue? Thank you. Jason >>> I'm discussing this with R&D right now. It's *conceivable*, because >>> there's an extra mixer stage in the below-450-mhz pathway, and that >>> mixer stage uses "high side" LO injection, which would produce an inverted >>> spectrum, but the FPGA would "know" this and invert it back... >>> >> Marcus, >> >> Did you ever get any resolution on this issue? >> >> Jason >> >> > I've raised the issue with R&D, but not heard back. I'm hampered by not > having an N320 in my own lab to test this. > > Presumably, the issue you see is version independent? > > > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
