I'm not super familiar with the octoclock-g, will it produce an output if the GPS isn't locked? I see what looks like a disconnected GPS Antenna connector, which would make it unlikely for the GPS to ever lock. Nick
On Fri, Jul 8, 2016 at 12:12 AM, Pavan Yedavalli <psy2...@columbia.edu> wrote: > It's an Octoclock-G (https://www.ettus.com/product/details/OctoClock-G is > what I ordered). And yes, that is true about the external clock inputs and > GPS lock. Does that matter if it's an Octoclock-G? > > On Thu, Jul 7, 2016 at 7:46 PM, <mle...@ripnet.com> wrote: > >> Is this an Octoclock, or Octoclock-G? >> >> If it's just an Octoclock, then it has no internal clocks, and acts as a >> high-quality clock/pps distributor. >> >> I notice you don't have the external clock inputs connected to anything, >> and there's no GPS LOCK indicator. >> >> >> >> >> >> >> >> >> On 2016-07-07 17:08, Pavan Yedavalli wrote: >> >> Hi Marcus, >> >> I did what you suggested by wrapping the timed commands as follows: >> >> For the TX side (what you sent me in for_pavan.py): >> >> self.uhd_usrp_source_0.set_time_unknown_pps(uhd.time_spec()) >> now = self.uhd_usrp_source_0.get_time_now() >> start_time = now + uhd.time_spec(.5) >> self.uhd_usrp_source_0.set_command_time(start_time) >> self.uhd_usrp_source_0.set_clock_source("external", 0) >> self.uhd_usrp_source_0.set_time_source("external", 0) >> self.uhd_usrp_source_0.set_clock_source("external", 1) >> self.uhd_usrp_source_0.set_time_source("external", 1) >> self.uhd_usrp_source_0.set_samp_rate(samp_rate) >> self.uhd_usrp_source_0.set_time_unknown_pps(uhd.time_spec()) >> self.uhd_usrp_source_0.set_center_freq(rx_center_freq, 0) >> self.uhd_usrp_source_0.set_normalized_gain(rx_gain, 0) >> self.uhd_usrp_source_0.set_antenna(Antenna_sel, 0) >> self.uhd_usrp_source_0.set_center_freq(rx_center_freq, 1) >> self.uhd_usrp_source_0.set_normalized_gain(rx_gain, 1) >> self.uhd_usrp_source_0.set_antenna("TX/RX", 1) >> self.uhd_usrp_source_0.clear_command_time() >> >> And for the RX side (B210_Phase_Viewer.py): >> >> self.uhd_usrp_sink_0.set_time_unknown_pps(uhd.time_spec()) >> now = self.uhd_usrp_sink_0.get_time_now() >> start_time = now + uhd.time_spec(.5) >> self.uhd_usrp_sink_0.set_command_time(start_time) >> self.uhd_usrp_sink_0.set_clock_source("external", 0) >> self.uhd_usrp_sink_0.set_time_source("external", 0) >> self.uhd_usrp_sink_0.set_subdev_spec("A:0", 0) >> self.uhd_usrp_sink_0.set_clock_source("external", 1) >> self.uhd_usrp_sink_0.set_time_source("external", 1) >> self.uhd_usrp_sink_0.set_subdev_spec("A:0", 1) >> self.uhd_usrp_sink_0.set_samp_rate(samp_rate) >> self.uhd_usrp_sink_0.set_center_freq(915e6, 0) >> self.uhd_usrp_sink_0.set_gain(1.5, 0) >> self.uhd_usrp_sink_0.set_center_freq(915e6, 1) >> self.uhd_usrp_sink_0.set_gain(1.5, 1) >> self.uhd_usrp_sink_0.clear_command_time() >> >> >> However, it still does not work when I have the phase viewer running and >> stop and restart the for_pavan.py flowgraph. I had a run of three straight >> where the phase offset was around 11 degrees, but then afterward it started >> fluctuating again (-140, 45, 81 degrees, etc.). >> >> Attached is the front of the Octoclock. I believe the settings are >> correct, but maybe something is wrong with that. Note that the PPS flashes >> (but I couldn't capture when it flashed in the picture). Also note that I >> get the thread priority warning when running each of them, but I don't >> think that is a problem. >> >> I am really not sure what the issue is here, sadly. Thanks again for your >> help and patience. >> >> >> On Wed, Jul 6, 2016 at 6:22 PM, Marcus D. Leech <mle...@ripnet.com> >> wrote: >> >>> On 07/06/2016 09:04 PM, Pavan Yedavalli wrote: >>> >>> Hi Marcus, >>> >>> Trying the attached code with two of the USRPs transmitting, and with >>> the B210_Phase_Viewer for the other 2 USRPs receiving, still gives me >>> different offsets for every different run call. And by different run call, >>> I'm simply running the flowgraph once, seeing the offset, stopping the >>> graph, and then running it again, seeing the new offset, and so on. I must >>> be doing something wrong here. A you mentioned, since all of them are using >>> the Octoclock, that means that they all are having the same reference and >>> pps, but both receive boards may also not be timed in an aligned fashion >>> for the same reason, right? So the receive side LO offsets could also be >>> causing problems in narrowing down the issue, I'm assuming? Thanks again. >>> >>> Yes, the receive side needs to be as mutually-coherent as possible as >>> well. >>> >>> Also, I forgot to mention that you'll need to modify the output of the >>> flow-graph I provided to wrap timed-command stuff around the tuning. >>> >>> Same on any RX flow-graph. That's the only sane we to be able to >>> measure any kind of phase-offset that you can trust. >>> >>> If the RX side is a B210, you don't need to do timed commands (and, >>> indeed, they aren't supported for tuning on the B210). What I'd do is >>> leave the RX side running, while you bring the TX side up and down. >>> >>> >>> >>> >>> On Wed, Jul 6, 2016 at 5:47 PM, Marcus D. Leech <mle...@ripnet.com> >>> wrote: >>> >>>> On 07/06/2016 02:48 PM, Pavan Yedavalli wrote: >>>> >>>> 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). >>>> >>>> What about the attached code? >>>> >>>> Keep in mind that you'll have to measure it with something that is also >>>> mutually coherent. >>>> >>>> >>>> >>>> >>>> On Tue, Jul 5, 2016 at 9:11 PM, Marcus D. Leech <mle...@ripnet.com> >>>> 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 <mle...@ripnet.com> >>>>> 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 <mle...@ripnet.com> >>>>>> 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 <mle...@ripnet.com> >>>>>>> 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 <mle...@ripnet.com> >>>>>>>> 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, <mle...@ripnet.com> 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: mle...@ripnet.com >>>>>>>>>> Sent: Tuesday, July 5, 2016 12:35 PM >>>>>>>>>> Subject: Re: [Discuss-gnuradio] random phase offset constantly >>>>>>>>>> changing with octoclock setup >>>>>>>>>> To: Pavan Yedavalli <psy2...@columbia.edu> >>>>>>>>>> Cc: Discuss-gnuradio < >>>>>>>>>> discuss-gnuradio-bounces+mleech=ripnet....@gnu.org>, GNURadio >>>>>>>>>> Discussion List <discuss-gnuradio@gnu.org> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 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 >>>>>>>>>> Discuss-gnuradio@gnu.org >>>>>>>>>> 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 >>>> >>>> >>> >>> >>> -- >>> Pavan >>> >>> >> >> >> -- >> Pavan >> >> > > > -- > Pavan > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
