discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Python synchronisation of 2xUSRP N200 with SBX in


From: Marcus D. Leech
Subject: Re: [Discuss-gnuradio] Python synchronisation of 2xUSRP N200 with SBX in one UHD container.
Date: Sun, 17 Sep 2017 23:20:58 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0

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
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




reply via email to

[Prev in Thread] Current Thread [Next in Thread]