Hi Nick, yes, the Octoclock-G will output the 10 MHz from the undisciplined oven-controlled oscillator if no GPS is available.
Best regards, Marcus On 08.07.2016 07:05, Nick B 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 <[email protected] > <mailto:[email protected]>> 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, <[email protected] > <mailto:[email protected]>> 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 >> <[email protected] <mailto:[email protected]>> 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 >>> <[email protected] <mailto:[email protected]>> 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 >>>> <[email protected] <mailto:[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] >>>>> <mailto:[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] >>>>>> <mailto:[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] >>>>>>> <mailto:[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] >>>>>>>> <mailto:[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] >>>>>>>>> <mailto:[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] >>>>>>>>> <mailto:[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] >>>>>>>>> >>>>>>>>> <mailto:[email protected]>> >>>>>>>>> Cc: >>>>>>>>> Discuss-gnuradio >>>>>>>>> >>>>>>>>> <[email protected] >>>>>>>>> >>>>>>>>> <mailto:[email protected]>>, >>>>>>>>> GNURadio >>>>>>>>> Discussion List >>>>>>>>> <[email protected] >>>>>>>>> >>>>>>>>> <mailto:[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] >>>>>>>>> >>>>>>>>> <mailto:[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 >>> >>> >>> >>> >>> -- >>> Pavan >> >> >> >> >> -- >> Pavan > > > > > -- > Pavan > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] <mailto:[email protected]> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
