That makes sense. It probably is not perfectly matched to the waveform generator either. I noticed at lower frequencies (about 1 MHz), it begins to look more like a square wave with less ripple, so your explanation makes sense.
Having said that, I guess I'm a bit lost on where to go from here. It seems like the timed commands should be the solution to aligning the tuning, but for some reason that's not working. Did I wrap them around the correct commands? Thanks again. On Tue, Jul 12, 2016 at 6:03 PM, Marcus D. Leech <mle...@ripnet.com> wrote: > On 07/12/2016 08:56 PM, Pavan Yedavalli wrote: > > Hi Marcus, > > I have, and each PPS output of the Octoclock-G indeed pulses at once per > second. For the 10 MHz ref, attached are two plots on the scope from the > Octoclock-G (all the outputs end up being the same) (1902) and a square > wave signal from a waveform generator (1903). I'm not entirely sure why the > square waves are so jagged - perhaps there's something wrong with the > oscilloscope I'm using to measure (it goes up to 200 MHz, so I thought it > should be fine.) I'll try to check with another scope, but in the meantime, > it is indeed the same signal from each Octoclock-G ref port, so I think > that means the clock isn't the problem? > > > The jaggies are probably just because your scope isn't impedance matched > to the ports on the Octoclock-G, so there'll be some small > artifacts. > > > > > On Tue, Jul 12, 2016 at 4:40 PM, Marcus D. Leech <mle...@ripnet.com> > wrote: > >> On 07/12/2016 04:44 PM, Pavan Yedavalli wrote: >> >> Hi Nick, >> >> From what I saw on the Octoclock wiki page, it doesn't appear to need GPS: >> >> The OctoClock-G includes an internal GPSDO (GPS Disciplined Oscillator) >> which provides an internal source for 10 MHz and PPS from an OCXO high >> precision oscillator. Add a GPS antenna (optional) with a clear view of the >> sky for GPS Disciplining of the OCXO that futher enhances frequency >> accuracy of the OCXO and global time synchronization. >> >> Having said that, I still haven't been able to get the GPS to work, but >> it doesn't seem like that is what is causing this random offset problem. >> >> Have you actually looked at the 1PPS and 10MHz outputs on a scope? >> >> >> >> >> On Thu, Jul 7, 2016 at 10:05 PM, Nick B <n...@pelagiris.org> wrote: >> >>> 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 >>>>>>>>>>>>> >>>>>>>>>>>>> ... > > [Message clipped] -- Pavan
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
