I disconnected the MIMO cable and now have all 4 directly connected to the Octoclock, but I get the same results in which the offset changes at every run (using the above code).
On Tue, Jul 5, 2016 at 9:11 PM, Marcus D. Leech <[email protected]> wrote: > On 07/05/2016 11:45 PM, Pavan Yedavalli wrote: > > Yes, sorry - two of them are actually connected via MIMO cable, with the > master connected to the Octoclock. Then the other two are directly > connected to the Octoclock. I used the MIMO cable just because I had it, > but hopefully that's not changing the functionality. > > Yes, I added even more attenuation because the Tx gain was already quite > low. Thanks for the suggestion. > > So, a useful experiment would be to do your coherent TX from a pair that > are both hooked up to the Octoclock. > > > > > On Tue, Jul 5, 2016 at 7:29 PM, Marcus D. Leech <[email protected]> wrote: > >> On 07/05/2016 09:45 PM, Pavan Yedavalli wrote: >> >> According to the spectrum analyzer, there's nothing being transmitted in >> the 900 MHz band around me, so that is actually fine. The biggest unknown >> could be what you are saying about how they combine in the RSSI circuit >> (which I'm not sure how it works). >> >> I am not gaining any more insight when using over-the-air antennas, so I >> used 2 USRPs as transmitters and 2 as receivers, connected them directly >> with SMA cables (and attenuation), and used Derek Kozel's B210_Phase_Viewer >> on the receive side to see whether they were aligned after each run. And I >> am noticing that they are not. The first run produced a 125 degree phase >> offset, while the second one produced a 3 degree phase offset, and this >> continues to fluctuate after each run (see attached). Note that I am using >> the code that I pasted above to transmit. >> >> I must be doing something wrong with the code, or not wrapping the timed >> commands around the correct code. I am not sure though. Thanks again. >> >> Looks like you have a bit of clipping as well. Back off the gain on the >> TX side. >> >> >> >> >> On Tue, Jul 5, 2016 at 5:51 PM, Marcus D. Leech <[email protected]> >> wrote: >> >>> On 07/05/2016 08:20 PM, Pavan Yedavalli wrote: >>> >>> I see, but the offset in phase between the two radios will affect the >>> amplitude, right? That was the assumption I was using, since it gives out >>> an amplitude reading, but the phase clearly will affect that reading, I >>> presumed. >>> >>> Unfortunately, I don't have any documentation on the RSSI circuit apart >>> from the following description from the vendor: >>> >>> The RSSI functionality allows the sampling of the received signal to >>> provide an indication of the amount of energy being harvested. When DSET is >>> driven high the harvested DC power will be directed to an internal sense >>> resistor, and the corresponding voltage will be provided to the DOUT pin. >>> The voltage on the DOUT pin can be read after a 50μs settling time. RSSI >>> shows the actual power level that is being received at the antenna. This >>> number is accurate from 0.04mW to 50mW. >>> >>> This probably does not help at all to debug. Sorry about that. >>> >>> You're making assumptions about how your signals will combine in that >>> RSSI circuit, and how they'll combine with other ambient signals within >>> your frequency band. I cannot imagine that being stable. >>> >>> To measure the phase between two signals, you need a device that is >>> phase sensitive (like, for example, another USRP with two inputs), and >>> compute conjugate multiplication between them, or the phase-angle, via >>> the complex-argument block. >>> >>> Or just plot the two signals on a Qt Time sync, and observe that the >>> phase relationship is the same--that of course requires that your >>> receiver system is internally coherent between the two channels. >>> >>> >>> >>> >>> >>> On Tue, Jul 5, 2016 at 4:42 PM, Marcus D. Leech <[email protected]> >>> wrote: >>> >>>> On 07/05/2016 07:28 PM, Pavan Yedavalli wrote: >>>> >>>> The way I'm doing it is the following (please correct me if there is a >>>> fundamental error in assumptions): I am actually using an RSSI circuit that >>>> is receiving the power from the USRPs/antennas, and I'm determining whether >>>> the phase offset is the same based on that RSSI value. For example, I run >>>> the flowgraph once, and I get an RSSI value on the other side of 2.5 mW, >>>> but when I run the flowgraph again, it produces an RSSI value of 9.5 mW. In >>>> my mind, if that offset was constant, then it would have produced something >>>> around 2.5 mW again. I know this adds another variable to the mix, but I >>>> have confirmed the accurate functioning of the RSSI circuit/receiver as >>>> well as the static nature of the channel, so its reading is very reliable. >>>> >>>> Could you describe this RSSI circuit? Normally, they're only sensitive >>>> to amplitude, not phase. >>>> >>>> >>>> >>>> >>>> On Tue, Jul 5, 2016 at 4:19 PM, Marcus D. Leech <[email protected]> >>>> wrote: >>>> >>>>> On 07/05/2016 06:47 PM, Pavan Yedavalli wrote: >>>>> >>>>> Hi Marcus, >>>>> >>>>> Thanks for the background. That helps greatly. Having said that, I am >>>>> unclear which commands specifically tune the radios, so I did the >>>>> following >>>>> around the frequency tuning (after all of the time source, gain, and >>>>> antenna setting code): >>>>> >>>>> addr_string = "addr0=192.168.10.3,addr1=192.168.10.4" >>>>> self.uhd_usrp_sink_0_0 = uhd.usrp_sink( >>>>> ",".join((addr_string, "")), >>>>> uhd.stream_args( >>>>> cpu_format="fc32", >>>>> channels=range(2), >>>>> ), >>>>> ) >>>>> >>>>> >>>>> self.uhd_usrp_sink_0_0.set_clock_source("external", 0) >>>>> self.uhd_usrp_sink_0_0.set_time_source("external", 0) >>>>> self.uhd_usrp_sink_0_0.set_clock_source("mimo", 1) >>>>> self.uhd_usrp_sink_0_0.set_time_source("mimo", 1) >>>>> self.uhd_usrp_sink_0_0.set_samp_rate(samp_rate) >>>>> self.uhd_usrp_sink_0_0.set_gain(31.5, 0) >>>>> self.uhd_usrp_sink_0_0.set_gain(31.5, 1) >>>>> self.uhd_usrp_sink_0_0.set_antenna("TX/RX", 0) >>>>> self.uhd_usrp_sink_0_0.set_antenna("TX/RX", 1) >>>>> self.analog_sig_source_x_0_1 = analog.sig_source_c(samp_rate, >>>>> analog.GR_CONST_WAVE, 10000, 1, 0) >>>>> self.analog_sig_source_x_0_0_0 = >>>>> analog.sig_source_c(samp_rate, analog.GR_CONST_WAVE, 10000, 1, 0) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> * self.uhd_usrp_sink_0_0.set_time_unknown_pps(uhd.time_spec()) >>>>> now = self.uhd_usrp_sink_0_0.get_time_now() start_time = >>>>> now + uhd.time_spec(.5) >>>>> self.uhd_usrp_sink_0_0.set_command_time(start_time) >>>>> self.uhd_usrp_sink_0_0.set_center_freq(915000000, 0) >>>>> self.uhd_usrp_sink_0_0.set_center_freq(915000000, 1) >>>>> self.uhd_usrp_sink_0_0.clear_command_time()* >>>>> >>>>> >>>>> However, when running it, this does not appear to produce a constant >>>>> offset either, but I'm not sure whether this is the correct code to wrap >>>>> around. Please keep me posted. Thanks. >>>>> >>>>> On Tue, Jul 5, 2016 at 12:49 PM, <[email protected]> wrote: >>>>> >>>>>> That is precisely what I'm saying, and precisely what timed-commands >>>>>> for tuning were invented. On certain hardware, after the tune is >>>>>> complete, >>>>>> a phase-reset pulse is sent by the FPGA. The only way for THAT to have >>>>>> the >>>>>> desired effect is to make sure that the phase-reset pulse happens at the >>>>>> same instant. >>>>>> >>>>>> Modern synthesizers use a technique called fractional-N synthesis. >>>>>> One of the side effects of this is that you can't predict where the LO >>>>>> will >>>>>> "lock" with respect to the reference clock. So, any two PLL synthesizers, >>>>>> even when feed an identical reference clock, will not have the same phase >>>>>> offset with respect to one another. It's the "physics" of fractional-N >>>>>> PLL >>>>>> synthesis. >>>>>> >>>>>> SO, if you're using GRC to generate you flows, you'll have to modify >>>>>> the generated code, and wrap set_command_time()/clear_command_time() >>>>>> around >>>>>> the place in the code where it tunes the radios. >>>>>> >>>>>> Clearly, if this depends on TIME, then all radios involved need to >>>>>> agree on the current time, to high precision, hence the related >>>>>> requirement >>>>>> for set_time_unknown_pps(), which uses the 1PPS signal to trigger loading >>>>>> of the time-of-day clocks on each USRP in the multi_usrp object. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 2016-07-05 15:41, Pavan Srikrishna Yedavalli wrote: >>>>>> >>>>>> I am using USRP N210 with SBX daughterboards. All devices are >>>>>> connected to the octoclock ref and octoclock PPS. It would be nice to get >>>>>> phase alignment, but mere coherence-with-an-offset is sufficient if that >>>>>> offset stays constant across different runs of the file/flowgraph. Are >>>>>> you >>>>>> saying that that offset cannot be constant due to the randomness of the >>>>>> LO >>>>>> phase offset at each run? Thanks again. >>>>>> >>>>>> >>>>>> _____________________________ >>>>>> From: [email protected] >>>>>> Sent: Tuesday, July 5, 2016 12:35 PM >>>>>> Subject: Re: [Discuss-gnuradio] random phase offset constantly >>>>>> changing with octoclock setup >>>>>> To: Pavan Yedavalli <[email protected]> >>>>>> Cc: Discuss-gnuradio < >>>>>> [email protected]>, GNURadio >>>>>> Discussion List <[email protected]> >>>>>> >>>>>> >>>>>> WHat specific hardware line-up do you have? >>>>>> >>>>>> You have to use set_time_unknown_pps(), but also, if you want phase >>>>>> alignment (as opposed to mere coherence-with-an-offset), you need to use >>>>>> timed tuning commands across your systems. This will result in zero >>>>>> relative phase offset between boards, if you're using SBX or UBX (on the >>>>>> X310). Note that this is phase between the boards, there's no way to >>>>>> make >>>>>> certain the the LO phase has a predictable offset with respect to >>>>>> external >>>>>> received signals, only that the two LO phases agree. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 2016-07-05 15:26, Pavan Yedavalli wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> Despite all of my boards being connected via the Octoclock (ref and >>>>>> pps), I am constantly getting different phase offsets every time I run a >>>>>> gnuradio flowgraph (or python file). >>>>>> >>>>>> I am not sure why this is happening, but I do know that I need to >>>>>> call one of the functions, set_time_now() and/or set_time_unknown_pps(), >>>>>> to >>>>>> make sure all of them are synced. Which one am I supposed to call? I have >>>>>> been calling set_time_unknown_pps(), but I am getting the above/below >>>>>> problem with that, so maybe set_time_now() could be correct? >>>>>> >>>>>> In general, I don't understand why I continually get a different >>>>>> random phase offset of all of the radios after every new flowgraph run. >>>>>> Shouldn't this offset be the same if I continue to transmit at the same >>>>>> frequency? Would one of the above functions fix that? >>>>>> >>>>>> Hopefully that is clear. Thank you so much for the help. >>>>>> >>>>>> -- >>>>>> Pavan >>>>>> >>>>>> _______________________________________________ >>>>>> Discuss-gnuradio mailing list >>>>>> [email protected] >>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Pavan >>>>> >>>>> How are you measuring the phase-offset between the two sinks? >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Pavan >>>> >>>> >>>> >>> >>> >>> -- >>> Pavan >>> >>> >>> >> >> >> -- >> Pavan >> >> >> > > > -- > Pavan > > > -- Pavan
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
