Any type of active GPS antennna will work.
If you're using a passive antenna make sure you have a DC block in
place--some antennae are DC shorts.
On 2016-07-11 16:16, Pavan Yedavalli wrote:
> Hi Marcus,
>
> Is this the only type of GPS antenna that I can use on the Octoclock-G?
> https://www.ettus.com/product/details/GPS-ANT-3V
>
> Or can I use any other type of antenna at 1.57 GHz or 1.23 GHz?
>
> On Fri, Jul 8, 2016 at 1:33 PM, Pavan Yedavalli <psy2...@columbia.edu> wrote:
>
> The 1 PPS is flashing - it just wasn't flashing in the picture that I sent
> (captured the pic at the wrong time), so that appears to be working, but the
> GPS lock has never been on, I believe.
>
> I know that when I turn off the Octoclock-G, the received signals are all
> over the place, but with the Octoclock-G on, the received signals are much
> more coherent (just at the problem of completely random offsets). I figured
> that's confirmation that all of them are getting the proper 10 MHz reference
> clock, but maybe not? Thanks!
>
> On Fri, Jul 8, 2016 at 1:24 PM, <mle...@ripnet.com> wrote:
>
> Pavan:
>
> Do you have any way of verifying that you have 1PPS and 10MHz coming out of
> those ports on the Octoclock-G, as seen at the ends of the cables? [Looking
> for both the broken-Octoclock and broken-cables case].
>
> On 2016-07-08 00:12, Pavan Yedavalli 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
--
Pavan
--
Pavan_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
