Re: [USRP-users] Phase drift issue of N310
On 03/19/2019 09:12 PM, Damon wrote: Hi Marcus, The phase responses of two channels of different dboards (ubx-160) in a X310 are very consistent. When the frequency of transmitting signal changes from 460.01MHz to 460.03Mhz, the phase difference between two RX channels of different dboards in X310 remains unchanged. But for the phase difference between two RX channels of different dboards of N310, there are dozens or hundreds degree of changes. Can you try to reproduce the test and help me to figure out how to solve it? I'm not sure if it's a hardware bug, a driver bug or USRP setup problem. I cannot imagine a hardware or driver bug that could produce this behavior. It would mean that the receiver was somehow changing LO frequency when the TX frequency changed. Does this happen with *other* frequency changes, or just 460.01<--->460.03. I wonder if you have an interfering signal that is being "uncovered" by TX frequency change, and you're simply measuring that interfering signal? The only other thing that occurs to me is filtering that is extremely non-linear phase. But that would create such a mess that most applications would likely not work--clearly they do. I can try to reproduce in my lab tomorrow, but, like the last tests I did, I very much expect to not be able to reproduce. Best regards, Damon On 2019/3/19 上午6:10, Marcus D. Leech wrote: On 03/18/2019 01:26 PM, Damon wrote: Hi Marcus, Sorry, I can't reproduce the first observation in this discussion thread. A new problem about phase response has arisen. I am testing the phase coherence performance of four receiving channels of N310. A B200 is transmitting single tone continuous wave to a one to four splitter. The 4 outputs of the splitter are connected to 4 RX channels of N310. Attached please find the GRC file of this test. The RX frequency of 4 channels of N310 is set to 460MHz, and keep running in the test. The TX frequency of B200 is set to 460.02MHz first, and then to 460.03MHz. I thought the phase difference between different dboards would change very little when the signal frequency difference is very small, similar to the performance of X310. However, the fact is that the phase difference between the two dboards of N310 varies considerably with the signal frequency transmission. For example, in the attached picture, when the signal frequency is 460.01MHz, the phase difference between channel 2 and channel 0 is -118 degrees, the phase difference between channel 1 and channel 0 is 0 degrees; when the transmission frequency is adjusted to 460.03MHz, the phase difference between channel 2 and channel 0 is 117 degrees, and the phase difference between channel 1 and channel 0 is 0 degrees. It is very difficult to understand that the phase difference of two receiving channels of two different dboards has changed by 235 degrees with the signal frequency change of 20 KHz. The phase difference of two receiving channels of the same dboard is basically unchanged. Best regards, Damon Since the LO on the daughterboards has no idea that you've changed input frequency, this is clearly a measurement thing, and it's up to you to understand what you're measuring, and why. On 2019/3/16 上午7:47, Marcus D. Leech wrote: On 03/14/2019 04:37 PM, Damon wrote: Hi Marcus, The UHD Version is v3.14.0.0-rc1. Best regards, Damon I don't see this issue at all, using v3.14.0.0-rc3 How are you measuring phase, what does you flow-graph look like? Have you increased the gain enough to assure that the inherent system noise is not dominating your phase measurements? Hi Ali, The daughterboards have their own clock generators, but they are not exactly 'independent'. At least they don't have to be, as they share the same reference clock. Look at the block diagram: https://kb.ettus.com/images/9/9d/USRP_N310_N300_DB_Schematic.pdf and "Ref Clock" block. I don't have N310 and I know that reality can be a bit far from expectations (i.e. look at my "What makes sense and what doesn't in the way carrier frequency is set for TwinRX currently?" post). But maybe the daughterboards can be configured to use that reference clock. Best Regards, Piotr Krysik The LMK clock generator uses the reference clock from the mainboard, so there should not be any mutual phase-jitter/drift issues. I can test this on my N310 in the coming day or two. What version of UHD is in use? ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Phase drift issue of N310
Hi Marcus, The phase responses of two channels of different dboards (ubx-160) in a X310 are very consistent. When the frequency of transmitting signal changes from 460.01MHz to 460.03Mhz, the phase difference between two RX channels of different dboards in X310 remains unchanged. But for the phase difference between two RX channels of different dboards of N310, there are dozens or hundreds degree of changes. Can you try to reproduce the test and help me to figure out how to solve it? I'm not sure if it's a hardware bug, a driver bug or USRP setup problem. Best regards, Damon On 2019/3/19 上午6:10, Marcus D. Leech wrote: On 03/18/2019 01:26 PM, Damon wrote: Hi Marcus, Sorry, I can't reproduce the first observation in this discussion thread. A new problem about phase response has arisen. I am testing the phase coherence performance of four receiving channels of N310. A B200 is transmitting single tone continuous wave to a one to four splitter. The 4 outputs of the splitter are connected to 4 RX channels of N310. Attached please find the GRC file of this test. The RX frequency of 4 channels of N310 is set to 460MHz, and keep running in the test. The TX frequency of B200 is set to 460.02MHz first, and then to 460.03MHz. I thought the phase difference between different dboards would change very little when the signal frequency difference is very small, similar to the performance of X310. However, the fact is that the phase difference between the two dboards of N310 varies considerably with the signal frequency transmission. For example, in the attached picture, when the signal frequency is 460.01MHz, the phase difference between channel 2 and channel 0 is -118 degrees, the phase difference between channel 1 and channel 0 is 0 degrees; when the transmission frequency is adjusted to 460.03MHz, the phase difference between channel 2 and channel 0 is 117 degrees, and the phase difference between channel 1 and channel 0 is 0 degrees. It is very difficult to understand that the phase difference of two receiving channels of two different dboards has changed by 235 degrees with the signal frequency change of 20 KHz. The phase difference of two receiving channels of the same dboard is basically unchanged. Best regards, Damon Since the LO on the daughterboards has no idea that you've changed input frequency, this is clearly a measurement thing, and it's up to you to understand what you're measuring, and why. On 2019/3/16 上午7:47, Marcus D. Leech wrote: On 03/14/2019 04:37 PM, Damon wrote: Hi Marcus, The UHD Version is v3.14.0.0-rc1. Best regards, Damon I don't see this issue at all, using v3.14.0.0-rc3 How are you measuring phase, what does you flow-graph look like? Have you increased the gain enough to assure that the inherent system noise is not dominating your phase measurements? Hi Ali, The daughterboards have their own clock generators, but they are not exactly 'independent'. At least they don't have to be, as they share the same reference clock. Look at the block diagram: https://kb.ettus.com/images/9/9d/USRP_N310_N300_DB_Schematic.pdf and "Ref Clock" block. I don't have N310 and I know that reality can be a bit far from expectations (i.e. look at my "What makes sense and what doesn't in the way carrier frequency is set for TwinRX currently?" post). But maybe the daughterboards can be configured to use that reference clock. Best Regards, Piotr Krysik The LMK clock generator uses the reference clock from the mainboard, so there should not be any mutual phase-jitter/drift issues. I can test this on my N310 in the coming day or two. What version of UHD is in use? ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] X310 set_timed_command and get_gpio_attr
Hello, I have multi_usrp setup with many USRPs that are all doing timed sampling. The sampling intervals need to be as fast as 1ms sampling for 999us. In addition, at the start of the sample window, I need to grab the state of the GPIO pins on the front panel. I have tried the following : Single rx_streamer for all channels (as many as 10): streamCmd.num_samps = numGates; streamCmd.stream_now = true; streamCmd.time_spec = 0.0; usrp_->set_command_time( startTime ); rxStream_->issue_stream_cmd( streamCmd ); gpio = usrp_->get_gpio_attr( "FP0", "READBACK" ); usrp_->clear_command_time(); This works for one channel fairly well, but when multiple channels are used the channels fail to time align. I then created a separate rx_streamer for each channel with the same block of code as above for each channel. In this scenario, the lowest number channel would timeout as much or more than 50% of the time. Next I tried individual streamers as follows : streamCmd.num_samps = numGates; streamCmd.stream_now = false; streamCmd.time_spec = startTime; rxStream_->issue_stream_cmd( streamCmd ); I only allow 10 stream commands to be queued to the usrp for each channel and then only issue another stream command after a successful receive. In another thread I do the following figuring I can merge the gpio data with the sampled data after: usrp_->set_command_time( startTime ); gpio = usrp_->get_gpio_attr( "FP0", "READBACK" ); usrp_->clear_command_time(); uhd::time_spec_t response_time = usrp_->get_time_now(); I see between 50us and 250us latency between startTime and response_time assuming that the bits were actually read at the startTime. Unfortunately in this scenario, I see channels timing out and not recovering on occasion. CPU Utilization is fairly low as is network bandwidth. Does anyone have any suggestions? Thanks, Mike ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] RFNoC DDC/Radio block/port restrictions
Yes. Thanks! On Tue, Mar 19, 2019 at 2:10 PM Brian Padalino wrote: > On Tue, Mar 19, 2019 at 1:52 PM Rob Kossler via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> Hi, >> Are there restrictions regarding which DDC ports must be connected to >> which Radio ports. I am using an X310/UBX with a custom C++ rfnoc >> application and would like to do the following: >> Radio_0:port0 -> DDC_0:port0 >> Radio_1:port0 -> DDC_0:port1 >> Unfortunately, this fails (using default FPGA image) with a recv() after >> about 3K samples. If I simply change the 2nd link above to the following, >> then everything is fine. >> Radio_1:port0 -> DDC_1:port1 >> >> Why is the first config invalid? If this is a bug, is it presently being >> worked on? >> > > Radio produces samples at 200Msps. Each AXI bus port is 64-bits wide and > around 180-ish MHz. > > So you are limited by the AXI bus bandwidth. > > Does that make sense? > > Brian > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] RFNoC DDC/Radio block/port restrictions
On Tue, Mar 19, 2019 at 1:52 PM Rob Kossler via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi, > Are there restrictions regarding which DDC ports must be connected to > which Radio ports. I am using an X310/UBX with a custom C++ rfnoc > application and would like to do the following: > Radio_0:port0 -> DDC_0:port0 > Radio_1:port0 -> DDC_0:port1 > Unfortunately, this fails (using default FPGA image) with a recv() after > about 3K samples. If I simply change the 2nd link above to the following, > then everything is fine. > Radio_1:port0 -> DDC_1:port1 > > Why is the first config invalid? If this is a bug, is it presently being > worked on? > Radio produces samples at 200Msps. Each AXI bus port is 64-bits wide and around 180-ish MHz. So you are limited by the AXI bus bandwidth. Does that make sense? Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] RFNoC DDC/Radio block/port restrictions
Hi, Are there restrictions regarding which DDC ports must be connected to which Radio ports. I am using an X310/UBX with a custom C++ rfnoc application and would like to do the following: Radio_0:port0 -> DDC_0:port0 Radio_1:port0 -> DDC_0:port1 Unfortunately, this fails (using default FPGA image) with a recv() after about 3K samples. If I simply change the 2nd link above to the following, then everything is fine. Radio_1:port0 -> DDC_1:port1 Why is the first config invalid? If this is a bug, is it presently being worked on? FYI, my UHD version is UHD_3.14.0.0-20-gf63c089a. Rob ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] (no subject)
Hello, I am using USRP N310 , how can i use the external clock LO IN 0/1 and 2/3 in GNURadio? Also i would like to know witch API is better to develop aplication in this device, GNURadio, or Matlab? Best regards Diogo ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
