Hi, everyone. I am doing the estimation angle of arrival by using USRP.
The problem I want to fix is the initial phase offset of each dboards. >From now on, I have searched some knowledge about this issue. But I can not implement the concept. those concept I got are below: 1. Some kinds of dboard’s initial phase offset can remain constant after re-tune by timed command (code) http://files.ettus.com/manual/page_sync.html 2 <http://files.ettus.com/manual/page_sync.html> 1. I saw some AOA finding hardware set using another usrp or dboard to transmit a reference signal into the USRPs which are receivers connected to antenna array elements. https://decibel.ni.com/content/docs/DOC-25716 1 <https://decibel.ni.com/content/docs/DOC-25716> My simple hardware set is below: Two usrp N200 (with UBX). An octoclock to provide the reference signal. /---/ Theoretically, I would to send and to receive the same signal, I would get same waveform (phase). But I get a different offset and I find the offset is not constant. Summary of the problems: 1. I do not know where and how to add those ‘timed commands’ which taught in the USRP Hardware Driver and USRP Manual. (I saw someone said that I can do nothing and the initial offset of UBX will remain constant after retuning. But the result tell me it’s not true.) 2. Can anybody provide or teach me the code of phase calibration by using another USRP? I really do not understand how to set the gnuradio blocks to complete these work. Any example could provide to me or anyone can help me? Thank you very much for any help. Simona Il giorno mar 20 ago 2019 alle ore 17:26 <[email protected]> ha scritto: > Send USRP-users mailing list submissions to > [email protected] > > 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 > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of USRP-users digest..." > > > Today's Topics: > > 1. B205 GPIO & UHD Python API (Louis Brown) > 2. Re: Incorrect RX time_spec values with X300, TwinRX, and > v3.14.1.0 (Neel Pandeya) > 3. Re: Incorrect RX time_spec values with X300, TwinRX, and > v3.14.1.0 (Jason Roehm) > 4. Re: Incorrect RX time_spec values with X300, TwinRX, and > v3.14.1.0 (Jason Roehm) > 5. Re: Incorrect RX time_spec values with X300, TwinRX, and > v3.14.1.0 (Neel Pandeya) > 6. Re: Incorrect RX time_spec values with X300, TwinRX, and > v3.14.1.0 (Jason Roehm) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 19 Aug 2019 11:22:38 -0500 > From: Louis Brown <[email protected]> > To: [email protected] > Subject: [USRP-users] B205 GPIO & UHD Python API > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > Are there any examples of accessing B205 GPIO via UHD Python API? I need > to control some hardware via SPI and can bit-bang it if needed. > > Thanks, > Lou > > > > > > ------------------------------ > > Message: 2 > Date: Mon, 19 Aug 2019 11:34:28 -0500 > From: Neel Pandeya <[email protected]> > To: Jason Roehm <[email protected]> > Cc: usrp-users <[email protected]> > Subject: Re: [USRP-users] Incorrect RX time_spec values with X300, > TwinRX, and v3.14.1.0 > Message-ID: > < > cacaxmv-xwdkp8ok_325k_hahwwuauesqjddd8-ckonrjy7g...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hello Jason: > > I also would have expected UHD 3.14.1.0 to have resolved this issue. > > Would you be able to send me a stand-alone program that I can use to > reproduce this problem? > > Also, I'm curious, do you have a GPSDO installed in your X300? > > --Neel Pandeya > > > > On Sun, 18 Aug 2019 at 13:19, Jason Roehm via USRP-users < > [email protected]> wrote: > > > > > On 8/16/19 10:32 PM, Marcus D. Leech via USRP-users wrote: > > > On 08/16/2019 04:54 PM, Jason Roehm via USRP-users wrote: > > >> I have a software application that interfaces to an X300 with a > > >> TwinRX daughterboard installed. We recently upgraded our UHD version > > >> to v3.14.1.0 in our application. Since then, we've observed that the > > >> time_spec values on consecutive blocks of data received from the unit > > >> (i.e. from two sequential calls to rx_streamer::recv()) are not > > >> consistent with one another. The timecodes reported by the unit seem > > >> to be moving forward at twice real time. > > >> > > >> As an example, assume that I have the X300 configured for a sample > > >> rate of 100 MSPS, and that I'm getting 1000 samples per call to > > >> recv() (these are just round numbers to simplify the discussion). I'm > > >> seeing metadata from consecutive recv() calls that look like this: > > >> > > >> Block 1: > > >> - time_spec.get_whole_secs(): 0 > > >> - time_spec.get_frac_secs(): 0 > > >> - 1000 samples @ 100 MHz = 10 usec of data > > >> > > >> Block 2: > > >> - time_spec.get_whole_secs(): 0 > > >> - time_spec.get_frac_secs(): 0.000020 (where I would have expected > > >> 0.000010 instead) > > >> - 1000 samples @ 100 MHz = 10 usec of data > > >> > > >> ... and so on. > > >> > > >> If you watch the stream of timestamps received from the device, it > > >> looks like time is passing at twice the appropriate rate. I noticed > > >> this recent commit that seemed could be related: > > >> > > >> > > > https://github.com/EttusResearch/uhd/commit/5f75f73f25016958ab32710bb0cbd5ce4481041b > > >> > > >> > > >> If I revert that commit, then the timekeeping on the TwinRX channel > > >> works properly again. However, that isn't a fix that I can work with; > > >> I also use this hardware in a configuration where the X300 has a > > >> TwinRX and LFRX daughterboard installed simultaneously. Without the > > >> above commit, then I am unable to stream data from the LFRX; the > > >> rx_streamer never returns any data for that channel. I previously > > >> reported that problem > > >> ( > > > http://ettus.80997.x6.nabble.com/USRP-users-X300-with-TwinRX-and-LFRX-under-UHD-v3-14-td12749.html > ) > > > > >> and never got an answer, but the above commit silently fixed it in > > >> v3.14.1.0. > > >> > > >> How can I get correct timekeeping with the X300/TwinRX, while > > >> maintaining my ability to stream from a TwinRX and LFRX > simultaneously? > > >> > > >> Jason > > >> > > >> > > > I THINK this is fixed in commit: > > > > > > f712d477b97e2ee7cca56d5afcf199f00959eb85 > > > > > That commit is already included in v3.14.1.0 (and this code was later > > amended by commit 4eb12b031f9cad3df3e294db466bd26dee6b78e1, see > > > > > https://github.com/EttusResearch/uhd/commit/4eb12b031f9cad3df3e294db466bd26dee6b78e1 > ). > > > > So, I don't think that is a fix for this problem. > > > > Jason > > > > > > _______________________________________________ > > USRP-users mailing list > > [email protected] > > 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/20190819/774bc23e/attachment-0001.html > > > > ------------------------------ > > Message: 3 > Date: Mon, 19 Aug 2019 14:07:58 -0400 > From: Jason Roehm <[email protected]> > To: Neel Pandeya <[email protected]> > Cc: usrp-users <[email protected]> > Subject: Re: [USRP-users] Incorrect RX time_spec values with X300, > TwinRX, and v3.14.1.0 > Message-ID: <[email protected]> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > > On 8/19/19 12:34 PM, Neel Pandeya wrote: > > Hello Jason: > > > > I also would have expected UHD 3.14.1.0 to have resolved this issue. > > > > Would you be able to send me a stand-alone program that I can use to > > reproduce this problem? > > > > Also, I'm curious, do you have a GPSDO installed in your X300? > > > > --Neel Pandeya > > Neel, > > I don't have a standalone reproducer at the moment. I will generate one > when I get a chance, but it may be a little while before I can get back > to you with one. We do have a GPSDO installed in the X300. Would you > expect any differences in behavior without it? > > Thanks. > > Jason > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20190819/fc814874/attachment-0001.html > > > > ------------------------------ > > Message: 4 > Date: Mon, 19 Aug 2019 14:33:22 -0400 > From: Jason Roehm <[email protected]> > To: usrp-users <[email protected]> > Subject: Re: [USRP-users] Incorrect RX time_spec values with X300, > TwinRX, and v3.14.1.0 > Message-ID: <[email protected]> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > > On 8/19/19 12:34 PM, Neel Pandeya wrote: > > Hello Jason: > > > > I also would have expected UHD 3.14.1.0 to have resolved this issue. > > > > Would you be able to send me a stand-alone program that I can use to > > reproduce this problem? > > > > Also, I'm curious, do you have a GPSDO installed in your X300? > > > > --Neel Pandeya > > > Neel, > > Also, if it helps, I had traced the problem down a bit further when I > was originally debugging it last week. I found that the code in > super_recv_packet_handler.hpp, which translates the packets from the > device into samples and metadata that are passed to the UHD client, > thought that the tick rate was 100 MHz (recv_packet_handler::_tick_rate > was equal to 100e6). However, the X300 with a TwinRX installed must > always use a master clock rate of 200 MHz per the documentation. So the > effect was that the timestamps received in the packets from the X300 > were ticking up at a rate of 200 MHz, but the code in > recv_packet_handler believed that the tick rate was 100 MHz instead; > hence the 2x real-time rate. I was not able to find out how that tick > rate was actually getting to the recv_packet_handler, however. > > Jason > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20190819/df7cd97e/attachment-0001.html > > > > ------------------------------ > > Message: 5 > Date: Mon, 19 Aug 2019 17:52:35 -0500 > From: Neel Pandeya <[email protected]> > To: Jason Roehm <[email protected]> > Cc: usrp-users <[email protected]> > Subject: Re: [USRP-users] Incorrect RX time_spec values with X300, > TwinRX, and v3.14.1.0 > Message-ID: > < > cacaxmv87s56ttkck4io8z5njq3djyhzl6qv1pgtmuvahmsa...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hello Jason: > > Thanks for all the detailed feedback! No worries about not having a > stand-alone reproducing program at the moment. Could you please try using > the head of the "UHD-3.14" branch? We just tagged v3.14.1.1-rc1 with some > bug fixes, which we think should address the issue. Please let me know > your results running with that, and we'll go from there. > > --Neel Pandeya > > > > On Mon, 19 Aug 2019 at 13:34, Jason Roehm via USRP-users < > [email protected]> wrote: > > > > > On 8/19/19 12:34 PM, Neel Pandeya wrote: > > > > Hello Jason: > > > > I also would have expected UHD 3.14.1.0 to have resolved this issue. > > > > Would you be able to send me a stand-alone program that I can use to > > reproduce this problem? > > > > Also, I'm curious, do you have a GPSDO installed in your X300? > > > > --Neel Pandeya > > > > Neel, > > > > Also, if it helps, I had traced the problem down a bit further when I was > > originally debugging it last week. I found that the code in > > super_recv_packet_handler.hpp, which translates the packets from the > device > > into samples and metadata that are passed to the UHD client, thought that > > the tick rate was 100 MHz (recv_packet_handler::_tick_rate was equal to > > 100e6). However, the X300 with a TwinRX installed must always use a > master > > clock rate of 200 MHz per the documentation. So the effect was that the > > timestamps received in the packets from the X300 were ticking up at a > rate > > of 200 MHz, but the code in recv_packet_handler believed that the tick > rate > > was 100 MHz instead; hence the 2x real-time rate. I was not able to find > > out how that tick rate was actually getting to the recv_packet_handler, > > however. > > > > Jason > > _______________________________________________ > > USRP-users mailing list > > [email protected] > > 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/20190819/a281cbf4/attachment-0001.html > > > > ------------------------------ > > Message: 6 > Date: Tue, 20 Aug 2019 07:40:04 -0400 > From: Jason Roehm <[email protected]> > To: Neel Pandeya <[email protected]> > Cc: usrp-users <[email protected]> > Subject: Re: [USRP-users] Incorrect RX time_spec values with X300, > TwinRX, and v3.14.1.0 > Message-ID: <[email protected]> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > > On 8/19/19 6:52 PM, Neel Pandeya wrote: > > Hello Jason: > > > > Thanks for all the detailed feedback!? No worries about not having a > > stand-alone reproducing program at the moment.? Could you please try > > using the head of the "UHD-3.14" branch?? We just tagged v3.14.1.1-rc1 > > with some bug fixes, which we think should address the issue.? Please > > let me know your results running with that, and we'll go from there. > > > > --Neel Pandeya > > > Neel, > > I saw the same behavior with the UHD-3.14 branch. I was able to take the > time to put together a self-contained reproducer; see the attached > source file. It's just a simple C++ program that initializes the USRP, > streams a few blocks of data in, and checks the timestamps of > consecutive blocks for continuity. When I run it, I see the following > output: > > [jasonr@host:~/test_uhd]$ LD_LIBRARY_PATH=~/git/sceptre/deps/lib > ./test_uhd > [INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106900; > UHD_3.14.1.HEAD-0-g98c7c986 > [INFO] [X300] X300 initialization sequence... > [INFO] [X300] Maximum frame size: 8000 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) > [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1303 MB/s) > [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1312 MB/s) > [INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD100000000001) > [INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD100000000001) > [INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0000000000000) > [INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0000000000000) > [INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C0000000000000) > [INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C0000000000000) > [WARNING] [X300] Cannot update master clock rate! X300 Series does not > allow changing the clock rate during runtime. > Block 1: 16384 samples @ 100 MSPS > ??? Timestamp:?????????? 1.96557 > Block 2: 16384 samples @ 100 MSPS > ??? Timestamp:?????????? 1.9659 > ??? Last timestamp:????? 1.96557 > ??? Difference:????????? 0.00032352 > ??? Expected difference: 0.00016384 > Block 3: 16384 samples @ 100 MSPS > ??? Timestamp:?????????? 1.96622 > ??? Last timestamp:????? 1.9659 > ??? Difference:????????? 0.00032352 > ??? Expected difference: 0.00016384 > Block 4: 16384 samples @ 100 MSPS > ??? Timestamp:?????????? 1.96654 > ??? Last timestamp:????? 1.96622 > ??? Difference:????????? 0.00032352 > ??? Expected difference: 0.00016384 > Block 5: 16384 samples @ 100 MSPS > ??? Timestamp:?????????? 1.96687 > ??? Last timestamp:????? 1.96654 > ??? Difference:????????? 0.00032352 > ??? Expected difference: 0.00016384 > Block 6: 16384 samples @ 100 MSPS > ??? Timestamp:?????????? 1.96721 > ??? Last timestamp:????? 1.96687 > ??? Difference:????????? 0.00034348 > ??? Expected difference: 0.00016384 > Block 7: 16384 samples @ 100 MSPS > ??? Timestamp:?????????? 1.96753 > ??? Last timestamp:????? 1.96721 > ??? Difference:????????? 0.00032352 > ??? Expected difference: 0.00016384 > Block 8: 16384 samples @ 100 MSPS > ??? Timestamp:?????????? 1.96786 > ??? Last timestamp:????? 1.96753 > ??? Difference:????????? 0.00032352 > ??? Expected difference: 0.00016384 > Block 9: 16384 samples @ 100 MSPS > ??? Timestamp:?????????? 1.96818 > ??? Last timestamp:????? 1.96786 > ??? Difference:????????? 0.00032352 > ??? Expected difference: 0.00016384 > Block 10: 16384 samples @ 100 MSPS > ??? Timestamp:?????????? 1.96851 > ??? Last timestamp:????? 1.96818 > ??? Difference:????????? 0.00032352 > ??? Expected difference: 0.00016384 > [jasonr@gauss:~/git/sceptre/test/test_uhd]$ > > Thanks for your help. > > Jason > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20190820/c6d115dd/attachment-0001.html > > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: test_uhd.cc > Type: text/x-c++src > Size: 2089 bytes > Desc: not available > URL: < > http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20190820/c6d115dd/attachment-0001.cc > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > USRP-users mailing list > [email protected] > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > > ------------------------------ > > End of USRP-users Digest, Vol 108, Issue 18 > ******************************************* >
_______________________________________________ USRP-users mailing list [email protected] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
