Here is the relevant code I
am executing:
self.uhd_usrp_source_0.set_clock_source('gpsdo', 0)
self.uhd_usrp_source_0.set_time_source('gpsdo', 0)
self.uhd_usrp_source_0.set_clock_source('mimo', 1)
self.uhd_usrp_source_0.set_time_source('mimo', 1)
self.uhd_usrp_source_0.set_samp_rate(samp_rate)
self.uhd_usrp_source_0.set_time_unknown_pps(uhd.time_spec())
# now put in code to make sure that both usrps have seen at least 1
pps - pulse
# self.save_last_pps=self.uhd_usrp_source_0.get_last_pps(0)
# as the USRPs have been running for hours will tackle the 'spin
until get_last_pps changes' code later
# inserted code to synch LO and, by way of the mechanism, align the
CORDICs
self.tune_time=self.uhd_usrp_source_0.get_time_now(0)+uhd.time_spec_t(0.1)
# tune in 100 msecs from 'now'
self.uhd_usrp_source_0.set_command_time(self.tune_time)
self.uhd_usrp_source_0.set_center_freq(freq, 0)
self.uhd_usrp_source_0.set_center_freq(freq, 1)
self.uhd_usrp_source_0.clear_command_time()
self.uhd_usrp_source_0.set_gain(rf_gain+.45, 0)
self.uhd_usrp_source_0.set_antenna('RX2', 0)
self.uhd_usrp_source_0.set_gain(rf_gain, 1)
self.uhd_usrp_source_0.set_antenna('RX2', 1)
when I run the FG, I get variable results - I attach 2 screenshots
which show the averaged phase difference is 74-odd degrees for one run
and the next run the result is 101-odd degrees. Clearly, I am doing
something wrong but, for the life of me, I cannot figure it out. For
completeness, I will later put this code, when it works into the
set_freq function but I don't have this parameter changeable in the FG.
Kind Regards,
John
On 18/09/17 03:20, Marcus D. Leech wrote:
> On 09/15/2017 05:38 PM, John Shields wrote:
>> Hi,
>>
>> One has O/B GPSDO, the other connected by MIMO cable on Ubuntu
>> with UHD_003.010.002.000
>>
>> From the /manual/page_sync.html page there is information on how
>> to align the CORDICs and LOs of SBX.
>>
>> I have modified the python generated by a GRC FG and here are the
>> relevant changes I made:
>>
>>
>> self.uhd_usrp_source_0.set_clock_source('gpsdo', 0)
>> self.uhd_usrp_source_0.set_time_source('gpsdo', 0)
>> self.uhd_usrp_source_0.set_clock_source('mimo', 1)
>> self.uhd_usrp_source_0.set_time_source('mimo', 1)
>> self.uhd_usrp_source_0.set_samp_rate(samp_rate)
>> self.uhd_usrp_source_0.set_time_unknown_pps(uhd.time_spec())
>> # inserted code to align CORDICs ?
>>
>>
>> # inserted code to synch LO
>> self.tune_time=self.uhd_usrp_source_0.get_time_now(0)+uhd.time_spec_t(0.1)
>> # tune in 100 msecs from 'now'
>> self.uhd_usrp_source_0.set_command_time(self.tune_time)
>> self.uhd_usrp_source_0.set_center_freq(freq, 0)
>> self.uhd_usrp_source_0.set_center_freq(freq, 1)
>> self.uhd_usrp_source_0.clear_command_time()
>>
>>
>> self.uhd_usrp_source_0.set_gain(rf_gain, 0)
>> self.uhd_usrp_source_0.set_antenna('RX2', 0)
>>
>> self.uhd_usrp_source_0.set_gain(rf_gain, 1)
>> self.uhd_usrp_source_0.set_antenna('RX2', 1)
>>
>>
>> While there is a discussion on the web re: the tune_time which seems
>> to suggest, I could just put in the, uhd.time_spec_t(0.1), there is a
>> comment from Josh saying to make sure the time is in the future so
>> that is why I added the time now.
>>
>>
>> In that same thread there were comments to the effect that
>> stream_cmds have not been swig-ed as the control of streaming is part
>> of the scheduler so:
>>
>> questions:
>>
>> 1) have I got the correct code to synch the LO i.e. by tuning
>> both devices at the same exact time?
> Yes. That will have the effect of asserting the "phase resynch" pin
> on the SBX's synthesizer at the exact same time.
>
>>
>> 2) based on the comment about stream synch being controlled by
>> the scheduler, what do I need to do re: synching the CORDICs?
> That should happen as a side effect of tuning at the same time.
>
>>
>> 3) I have noticed that sometimes when I print out the
>> real_seconds of time_now, it has a low number (likely the number of
>> seconds the USRPs have been running.
>>
>> -- Setting references to the internal GPSDO
>> -- 1) catch time transition at pps edge
>> -- 2) set times next pps (synchronously)
>>
>> I presume that I am reading the time_now before it is synched
>> at the next pps where the value of time goes to 1505510864.00000 . If
>> the answer to 1) is that my code is correct, how do I make sure that
>> the pps edge has occurred before I get_time_now ?
> Do a get_time_last_pps, saved that value. Spin doing
> get_time_last_pps until it is different from the saved value. Pause a
> few 10s of milliseconds on each
> spin.
>
>
>>
>> 4) the sync document also implies that the phase offset will
>> drift (due to thermal and other characteristics) so phase-coherent
>> applications will need re-calibration. is this done by somehow
>> stopping the stream(s), doing a set_freq and whatever the answer to
>> 2) above is and then restarting. I am trying to collect complex
>> visibilities over a long period of time ( i.e. fringe stopping) so
>> wonder if the drift is slow enough whether I need to do the
>> "calibration" mentioned in the sync doc?
> Slow phase rotation is just a an inevitable property of analog
> hardware and temperature differentials. Some of the big
> observatories do active
> mitigation by sending measurement tones down the coax toward the
> antenna and measuring phase slip, and compensating.
>
> In my experience, I don't see this on our 600Mhz interferometer after
> it has equilibrated after start-up.
>
> What is the reason for fringe-stopping? In small-scale amateur
> observations, it is mostly a "frill". I have thought of using it for
> interferometric
> pulsar observations, where you want to keep the correlation at
> maximum over a long period (at least as long as the primary
> field-of-view).
>
>
>>
>>
>> Kind Regards,
>>
>>
>> John
>>
>>
>>
>> _______________________________________________
>> 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
>
No comments:
Post a Comment