Hi everyone, I am writing to you regarding Synchronization and MIMO capabilities with USRP Devices. I am using two N200s with UBX-40. I would like to implement the same example in GNU radio that there is in the following link: https://kb.ettus.com/Synchronization_and_MIMO_Capability_with_USRP_Devices
I would like to calibrate the phase using the phase shift module. But, I did not find this module in GNU radio WX widgets. Could you help me? Thank you for your time. Sorry for the previous email, but I had not added every mail address. Best Regards, Simona Il giorno mar 1 ott 2019 alle ore 17:00 <usrp-users-requ...@lists.ettus.com> ha scritto: > Send USRP-users mailing list submissions to > usrp-users@lists.ettus.com > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > or, via email, send a message with subject or body 'help' to > usrp-users-requ...@lists.ettus.com > > You can reach the person managing the list at > usrp-users-ow...@lists.ettus.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of USRP-users digest..." > > > Today's Topics: > > 1. Re: next pps issues with TwinRX (Jason Matusiak) > 2. X310 image 8 bytes too large with default image > (Francesco Restuccia) > 3. uhd_usrp_loader script defaults firmware to pre-built bin > file (Francesco Restuccia) > 4. Re: uhd_usrp_loader script defaults firmware to pre-built bin > file (Marcus D. Leech) > 5. Re: X310 image 8 bytes too large with default image (Paolo Palana) > 6. Re: USRP X310 problem (Paolo Palana) > 7. uhd_usrp_loader script defaults firmware to pre-built bin > file (Francesco Restuccia) > 8. [UHD] 3.14.1.1 Release Announcement (Michael West) > 9. Re: One sample - 5 ns delay between the two RF signals/ X310 > (Daniel Jepson) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 30 Sep 2019 17:23:43 +0000 > From: Jason Matusiak <ja...@gardettoengineering.com> > To: Neel Pandeya <neel.pand...@ettus.com> > Cc: usrp-users <usrp-users@lists.ettus.com> > Subject: Re: [USRP-users] next pps issues with TwinRX > Message-ID: > < > bl0pr12mb234012376a189c9c2ea5efdcaf...@bl0pr12mb2340.namprd12.prod.outlook.com > > > > Content-Type: text/plain; charset="iso-8859-1" > > Neel, > > I updated to: UHD_3.14.1.1-0-g0347a6d8 as well as v3.7.13.5 for GR, still > the same issues. > > It almost feels like some sort of double/float mismatch somewhere since > the alignment is so close to being right. > > ________________________________ > From: Neel Pandeya <neel.pand...@ettus.com> > Sent: Monday, September 30, 2019 11:19 AM > To: Jason Matusiak <ja...@gardettoengineering.com> > Cc: usrp-users <usrp-users@lists.ettus.com> > Subject: Re: [USRP-users] next pps issues with TwinRX > > Hello Jason: > > We'll look into this and get back to you shortly. > > If you get a chance, could you please try it with the tagged UHD 3.14.1.1 ? > > Which version of GNU Radio are you using? > > --Neel Pandeya > > > > On Mon, 30 Sep 2019 at 10:10, Jason Matusiak via USRP-users < > usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>> wrote: > We are having another issues with our TwinRXs. A co-worker has been > trying to get this to work for a while, but has had no luck with the PPS > timing. Here is the notes: > > We are running UHD_3.14.1.HEAD-12-g5f75f73f. > > The setup is a single X310 (revision: 11, revision_compat: 7) with two > TwinRX boards. The device gets Ref/PPS from an Octoclock. > > The attached script has a hard-coded IP address and clock rate. It works > for other X310s with UBX/SBX daughter boards as well as the E320. > > Good results are (note line 5 below): > > Synchronizing Radios to Reference Signals > Checking PPS synchronization > next_pps from 1569851984.633563 is 1569851985.000000 > Setting time for radio `gr uhd usrp source`: 2019-09-30 09:59:45 > PPS alignment PASSED!: [1569851986.0, 1569851986] > All radios are Synchronized > > Bad results are: > Synchronizing Radios to Reference Signals > Checking PPS synchronization > next_pps from 1569851508.136703 is 1569851509.000000 > Setting time for radio `gr uhd usrp source`: 2019-09-30 09:51:49 > PPS alignment mismatch: [1569851509.9999995, 1569851509] > > Any thoughts of why this might be happening? > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com<mailto:USRP-users@lists.ettus.com> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com< > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.ettus.com_mailman_listinfo_usrp-2Dusers-5Flists.ettus.com&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=W_MQLyUWPXWHfsF4mr51mTMqpeO4RbBBLexficV9DG8&m=VzsjpGSylp7F9peAKPOcnLbFzmAh8CNVnwzwket3hCo&s=_gOstnMMEDkfFbD1tcNsLqzHaSnMGcIjP7W9NVzbH6M&e= > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20190930/428148f5/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Mon, 30 Sep 2019 17:06:50 -0400 > From: Francesco Restuccia <fres...@gmail.com> > To: usrp-users@lists.ettus.com > Subject: [USRP-users] X310 image 8 bytes too large with default image > Message-ID: <b9a5e62a-1eed-95cd-9061-8ab7828ea...@gmail.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > Hi guys, > > I am responding to the following thread: > > http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-August/057669.html > > I am having the same problem while running the uhd_image_builder.py with > the default images for X310. > > See below: > > frank@frank-iMac:/opt/uhd/host/build/examples$ > "/opt/uhd_gnuradio_installs/bin/uhd_image_loader" > --args="type=x300,addr=192.168.10.15" > [INFO] [UHD] linux; GNU C++ version 8.3.0; Boost_106700; > UHD_3.15.0.git-71-g18bc320d > Error: RuntimeError: The specified FPGA image is too large: 15878040 vs. > 15878032 > > Any idea? I guess that this should NOT happen with default images > downloaded through uhd_images_downloader. > > Note that the USRP works by burning the default bitfile (HG version) > directly via Vivado and JTAG. > > Best, > > Francesco > > > > > > ------------------------------ > > Message: 3 > Date: Mon, 30 Sep 2019 17:58:35 -0400 > From: Francesco Restuccia <fres...@gmail.com> > To: usrp-users@lists.ettus.com > Subject: [USRP-users] uhd_usrp_loader script defaults firmware to > pre-built bin file > Message-ID: <4e2861db-3333-ffee-e0c0-cf8f525dc...@gmail.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > Dear all, > > I am trying to load my customized firmware into an USRP N210. I have > tried the following but it defaults to the default image, regardless of > the input: > > frank@frank-iMac:~$ uhd_image_loader > --args="type=usrp2,addr=192.168.10.2" > --fw-path="/opt/uhd/firmware/usrp2/build/usrp2p/usrp2p_txrx_uhd.bin" > --no-fpga > [INFO] [UHD] linux; GNU C++ version 8.3.0; Boost_106700; > UHD_3.15.0.git-71-g18bc320d > Unit: USRP N210 r4 (F2E28F, 192.168.10.2) > Firmware image: > /opt/uhd_gnuradio_installs/share/uhd/images/usrp_n210_fw.bin > -- Erasing firmware image...successful. > -- Writing firmware image...successful. > -- Verifying firmware image...successful. > > Any suggestion? > > Thanks, > > Francesco > > > > > ------------------------------ > > Message: 4 > Date: Mon, 30 Sep 2019 22:09:35 -0400 > From: "Marcus D. Leech" <patchvonbr...@gmail.com> > To: usrp-users@lists.ettus.com > Subject: Re: [USRP-users] uhd_usrp_loader script defaults firmware to > pre-built bin file > Message-ID: <5d92b55f.4040...@gmail.com> > Content-Type: text/plain; charset=windows-1252; format=flowed > > On 09/30/2019 05:58 PM, Francesco Restuccia via USRP-users wrote: > > Dear all, > > > > I am trying to load my customized firmware into an USRP N210. I have > > tried the following but it defaults to the default image, regardless > > of the input: > > > > frank@frank-iMac:~$ uhd_image_loader > > --args="type=usrp2,addr=192.168.10.2" > > --fw-path="/opt/uhd/firmware/usrp2/build/usrp2p/usrp2p_txrx_uhd.bin" > > --no-fpga > > [INFO] [UHD] linux; GNU C++ version 8.3.0; Boost_106700; > > UHD_3.15.0.git-71-g18bc320d > > Unit: USRP N210 r4 (F2E28F, 192.168.10.2) > > Firmware image: > > /opt/uhd_gnuradio_installs/share/uhd/images/usrp_n210_fw.bin > > -- Erasing firmware image...successful. > > -- Writing firmware image...successful. > > -- Verifying firmware image...successful. > > > > Any suggestion? > > > > Thanks, > > > > Francesco > > > Could you check to make sure the file is actually there and readable to > you? > > What does "which uhd_image_loader" return? > > > > > > ------------------------------ > > Message: 5 > Date: Tue, 1 Oct 2019 11:10:34 +0200 > From: Paolo Palana <p.pal...@itsystems.it> > To: usrp-users@lists.ettus.com > Subject: Re: [USRP-users] X310 image 8 bytes too large with default > image > Message-ID: <6d39763f-ea6e-9dcf-a38e-d0afeafe9...@itsystems.it> > Content-Type: text/plain; charset=utf-8 > > I had the same problem indeed, > I think this is because vivado 2017.4 output image size is a bit > different from the output imase size of vivado 2015.4. > I say so because the error did not appear with uhd-3.10.3. I think the > problem is that no one updated the tools provided with libuhd > used to configure the fpga in order to handle the new output file > dimension. > > My solution is very simple, if you are under Linux just use dd and copy > the original file with a command like this: > > dd if=<orig_file>.bit of=<new_file>.bit bs=<the_rigth_dimension> count=1 > > And it works, at least for me. In fact if you open the bit file with a > hexeditor you can see how the last bites looks like a padding. > > Best, > Paolo > > > On 30/09/19 23:06, Francesco Restuccia via USRP-users wrote: > > Hi guys, > > > > I am responding to the following thread: > > > http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-August/057669.html > > > > I am having the same problem while running the uhd_image_builder.py > > with the default images for X310. > > > > See below: > > > > frank@frank-iMac:/opt/uhd/host/build/examples$ > > "/opt/uhd_gnuradio_installs/bin/uhd_image_loader" > > --args="type=x300,addr=192.168.10.15" > > [INFO] [UHD] linux; GNU C++ version 8.3.0; Boost_106700; > > UHD_3.15.0.git-71-g18bc320d > > Error: RuntimeError: The specified FPGA image is too large: 15878040 > > vs. 15878032 > > > > Any idea? I guess that this should NOT happen with default images > > downloaded through uhd_images_downloader. > > > > Note that the USRP works by burning the default bitfile (HG version) > > directly via Vivado and JTAG. > > > > Best, > > > > Francesco > > > > > > > > _______________________________________________ > > USRP-users mailing list > > USRP-users@lists.ettus.com > > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > > > > > > ------------------------------ > > Message: 6 > Date: Tue, 1 Oct 2019 11:12:59 +0200 > From: Paolo Palana <p.pal...@itsystems.it> > To: usrp-users@lists.ettus.com > Subject: Re: [USRP-users] USRP X310 problem > Message-ID: <6b3db94d-518c-4604-6d13-52baca3a8...@itsystems.it> > Content-Type: text/plain; charset="utf-8" > > Try the command. > > dd if=<original_file>.bit of=<new_file>.bit count=<the_rigth_size> count=1 > > and then try to configure the fpga <new_file>.bit > > > On 27/09/19 16:12, Aaron Montilla via USRP-users wrote: > > Hi, > > I am trying to set the connection between my PC and my USRP X310. > > I ran the command uhd_find_devices, and successfully it found the > > USRP. Then I use the uhd_usrp_probe command and I had the next error: > > aaron@leonard:~$ uhd_usrp_probe > > [INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106501; > > UHD_3.15.0.git-71-g18bc320d > > [INFO] [X300] X300 initialization sequence... > > [INFO] [X300] Maximum frame size: 1472 bytes. > > [INFO] [X300] Radio 1x clock: 200 MHz > > [INFO] [GPS] Found an internal GPSDO: LC_XO, Firmware Rev 0.929a > > [INFO] [0/DmaFIFO_0] Initializing block control (NOC ID: > > 0xF1F0D00000000000) > > [ERROR] [0/DmaFIFO_0] Major compat number mismatch for noc_shell: > > Expecting 6, got 5. > > Error: RuntimeError: FPGA component `noc_shell' is revision 5 and UHD > > supports revision 6. Please either upgrade the FPGA image > > (recommended) or downgrade UHD. > > > > I thought that upgrade the USRP was the best option, but when I try, I > > have another error saying that the size of the image is too large ( > > only for 1 byte). I also read that I had to use the .bin file but I > > didn't have any. > > So, could you please tell me what I could do? > > > > Thank you very much in advance. > > Kind regards, > > Aaron > > > > _______________________________________________ > > USRP-users mailing list > > USRP-users@lists.ettus.com > > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20191001/ce515be1/attachment-0001.html > > > > ------------------------------ > > Message: 7 > Date: Tue, 1 Oct 2019 08:25:34 -0400 > From: Francesco Restuccia <fres...@gmail.com> > To: usrp-users@lists.ettus.com > Subject: [USRP-users] uhd_usrp_loader script defaults firmware to > pre-built bin file > Message-ID: <b358a6cc-0275-3f56-1533-178c9b837...@gmail.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > Hi Marcus, > > This is the output of the command: > > frank@frank-iMac:~$ which uhd_image_loader > /opt/uhd_gnuradio_installs/bin/uhd_image_loader > > And yes, the file should be ok: > > frank@frank-iMac:/opt/uhd$ ls -la > /opt/uhd/firmware/usrp2/build/usrp2p/usrp2p_txrx_uhd.bin > -rwxr-xr-x 1 frank frank 16383 Sep 30 17:26 > /opt/uhd/firmware/usrp2/build/usrp2p/usrp2p_txrx_uhd.bin > > Francesco > > > > > > ------------------------------ > > Message: 8 > Date: Tue, 1 Oct 2019 08:01:31 -0500 > From: Michael West <michael.w...@ettus.com> > To: discuss-gnura...@gnu.org, "USRP-users@lists.ettus.com" > <usrp-users@lists.ettus.com> > Subject: [USRP-users] [UHD] 3.14.1.1 Release Announcement > Message-ID: > < > cam4xkrrrt81qwyudoznldzefdawtxwsrp7rbpxhoz-yjsun...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > UHD 3.14.1.1 is now available! This is a patch release. It is API > compatible with 3.14.0.0 and ABI compatible with 3.14.1.0. This release > includes several bug fixes. > > Installers for Windows and Fedora are available here: > http://files.ettus.com/binaries/uhd/uhd_003.014.001.001-release/ > > The PPA for Ubuntu can be found here: > https://launchpad.net/~ettusresearch/+archive/ubuntu/uhd > > The tag for this release is located here: > https://github.com/EttusResearch/uhd/releases/tag/v3.14.1.1 > > There have been 67 commits since the last API release which can be viewed > here: > https://github.com/EttusResearch/uhd/compare/v3.14.0.0...v3.14.1.1 > > Please report any bugs found on the UHD issue tracker: > http://github.com/EttusResearch/uhd/issues > * Please do not use the issue tracker for help or support. > > Pull requests for direct code changes can be submitted to the UHD or FPGA > repositories: > http://github.com/EttusResearch/uhd/pulls > http://github.com/EttusResearch/fpga/pulls > > As always, we at Ettus Research would like to thank all of the UHD users in > the open source SDR community. This release contains commits from users in > the community that submitted pull requests against the UHD > <https://github.com/EttusResearch/uhd> and FPGA > <https://github.com/EttusResearch/fpga> repositories as well as many > commits that are a direct result of issues reported back to us by users > like you through the UHD <https://github.com/EttusResearch/uhd/issues> and > FPGA <https://github.com/EttusResearch/fpga/issues> issue trackers, > the USRP-users > mailing list > <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>, and > Ettus > support <supp...@ettus.com>. You have all helped contribute to the > continued improvement of UHD. Thank you! > > CHANGELOG: > ## 003.014.001.001 > Device3: latch n on m in axi_rate_change in DUC/DDC > Device3: UART: fix TX <-> RX, FIFO size as parameter > Device3: Restore default buffer sizes for MPMD UDP > RFNoC: Fix off by one error in window.v > E320: fix time source clobbering ref source > B200: Add command to query bootloader status > RFNoC: fix multidevice graph connections > MPMD: Fix corner case in MPM device discovery > MPM: fixed mboard_max_revision value (MPM compat check failures) > MPM: Fix version string for logger > Docs: x300: update docs for multiple timed commands > Docs: Fix Doxygen warnings due to spurious backslashes > Docs: RFNoC: Fix Doxygen warning due to undoc'd parameter > Docs: Adjust FPGA functional verification tests > Docs: Fix MPM cmake command for E320 > RFNoC: Re-enable flow ctrl for blocks on same xbar > Tools: Fix build issues with kitchen_sink > cmake: Add UHD_COMPONENT variable > > Best regards, > Michael > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20191001/e6cc6c67/attachment-0001.html > > > > ------------------------------ > > Message: 9 > Date: Tue, 1 Oct 2019 08:21:22 -0500 > From: Daniel Jepson <daniel.jep...@ettus.com> > To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com> > Subject: Re: [USRP-users] One sample - 5 ns delay between the two RF > signals/ X310 > Message-ID: > <CA+Zwmn6N5Fcb3NvcLO7met= > eeyweojb-hefzqqhcaugozf1...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Fabian, I had a hunch it was just the 3.3V part--thanks for clarifying! > > Cherif, the DAC interface timing (and for that matter, the ADC timing) > should be fairly tight. What you're seeing is expected and matches the > numbers we designed it to. The FPGA constraints are intentionally tight to > provide some extra margin at the DAC. Since this is all in the same X310, > you could start by isolating the various components of the design using the > front-panel GPIO connector. Run a trigger from each of your custom blocks > to the GPIO and see if they line up on a scope. If they don't, then you > might have a baseband timing issue (with how timed commands are interacting > with your blocks). If they line up, then it points to a timing failure in > the DAC. > > -Daniel > > > > On Fri, Sep 27, 2019 at 12:33 PM Cherif Diouf via USRP-users < > usrp-users@lists.ettus.com> wrote: > > > fabian, > > > > > > I have tested your solution, but the get_time_last_pps always gives me > > the expect value. > > > > > > > > Daniel, On a different point, the issue might be related to timing, here > > are some examples of timing related to the DACs. The compilation is > > successful but the margin is very low, in the 10 ps order. > > > > > > > > > > Startpoint Endpoint Slack(ns) > > > > > > > ---------------------------------------------------------------------------- > > gen_db1/gen_pins[2].oddr/C DB1_DAC_D2_N 0.016 > > > > gen_db1/gen_pins[2].oddr/C DB1_DAC_D2_P 0.016 > > > > gen_db1/gen_pins[7].oddr/C DB1_DAC_D7_N 0.021 > > > > gen_db1/gen_pins[7].oddr/C DB1_DAC_D7_P 0.021 > > > > gen_db1/gen_pins[3].oddr/C DB1_DAC_D3_N 0.024 > > > > gen_db1/gen_pins[3].oddr/C DB1_DAC_D3_P 0.024 > > > > > > > > gen_db0/gen_pins[2].oddr/C DB0_DAC_D2_N 0.066 > > > > gen_db0/gen_pins[2].oddr/C DB0_DAC_D2_P 0.066 > > > > gen_db0/gen_pins[0].oddr/C DB0_DAC_D0_N 0.071 > > > > gen_db0/gen_pins[0].oddr/C DB0_DAC_D0_P 0.071 > > > > gen_db0/oddr_frame/C DB0_DAC_FRAME_N 0.075 > > > > gen_db0/oddr_frame/C DB0_DAC_FRAME_P 0.075 > > > > gen_db0/gen_pins[3].oddr/C DB0_DAC_D3_N 0.080 > > > > gen_db0/gen_pins[3].oddr/C DB0_DAC_D3_P 0.080 > > > > gen_db0/gen_pins[1].oddr/C DB0_DAC_D1_N 0.085 > > > > gen_db0/gen_pins[1].oddr/C DB0_DAC_D1_P 0.085 > > > > > > > > Best Regards > > > > Cherif > > _______________________________________________ > > USRP-users mailing list > > USRP-users@lists.ettus.com > > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > > > > -- > > Daniel Jepson > > Digital Hardware Engineer > > National Instruments > > > > O: +1.512.683.6163 > > daniel.jep...@ni.com > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20191001/8ddd238e/attachment-0001.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > > ------------------------------ > > End of USRP-users Digest, Vol 110, Issue 1 > ****************************************** >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
