Re: [USRP-users] Synchronized frequency hopping

Fabian Schwartau via USRP-users Thu, 28 Jun 2018 03:54:02 -0700

Hi Derek,

I did what you suggested, but I have some synchroniziation issue betweenthe two USRP. The four channels within each USRP are synchronized, but Iget one out of three random phases between the two USRP at every start.Once initialized, the phases are constant.

My code for setting the frequency looks like this:


    uhd::tune_request_t tune_request(frequency, 0e6);
    tune_request.dsp_freq_policy = uhd::tune_request_t::POLICY_MANUAL;
    tune_request.dsp_freq = 0.0;
    for(int i=0; i<8; i++)
    {
        usrpDevice->set_rx_freq(tune_request, i);
    }

Is that correct?

Am 04.06.2018 um 14:45 schrieb Derek Kozel:

You should use a tune_request_t to manually specify the DSP frequency.The issue is that only the master (LO source) channel knows about theactual frequency error in the LO and will automatically use the DDC tocompensate for that error. The other channels must have the samecorrection applied manually.

http://files.ettus.com/manual/page_general.html#general_tuning

The GNU Radio UHD interface automatically does this. It is in Python,but the concept is fairly well illustrated.

https://github.com/gnuradio/gnuradio/blob/34f7e66e82079ef25b72ba6d6931fac05cfb968a/gr-uhd/apps/uhd_app.py#L219

Regards,
Derek

On Mon, Jun 4, 2018 at 1:14 PM, Fabian Schwartau via USRP-users<usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote:


    Hi Derek,

    I think I got that. Is the DDC frequency + offset aligned
    automatically if I use a timed command for usrp->set_rx_freq()? Or
    is there some other command I missed?

    Best regards,
    Fabian

    Am 04.06.2018 um 13:20 schrieb Derek Kozel:

        Fabian,

        Timed commands, carefully and correctly used along with common
        10 MHz and 1PPS, can give you time aligned reception with an
        accuracy of one sample clock period. They are used by many
        projects for this. To have repeatable phase relationships
        between channels you must also use timed commands to set the DDC
        frequency offset and decimation. This ensures that you have
        exactly matching frequency on all channels and exactly the
        number of samples produced on each stream so they stay inline.
        With the TwinRX you must use LO sharing between all channels to
        have repeatable phase offsets.

        The LOs take approximately 5mS to settle on the TwinRX, so for
        your application you can issue a tune command for time X, then a
        stream command for X + 5mS.
        
https://github.com/EttusResearch/uhd/blob/maint/host/examples/twinrx_freq_hopping.cpp
        
<https://github.com/EttusResearch/uhd/blob/maint/host/examples/twinrx_freq_hopping.cpp>

        Regards,
        Derek

        On Mon, Jun 4, 2018 at 11:47 AM, Fabian Schwartau via USRP-users
        <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>
        <mailto:usrp-users@lists.ettus.com
        <mailto:usrp-users@lists.ettus.com>>> wrote:

             Hello Derek,
             thank you very much.
             So is it correct, that the timing using the set_comman_time()
             function is so precise that I can do MIMO with it? That
        would be
             great :)

             Best regards,
             Fabian

             Am 04.06.2018 um 10:52 schrieb Derek Kozel:

                 Hello Fabien,

                 Yes, it is possible to queue commands, however there
        are two
                 important things to keep in mind. The commands will
        block any
                 other commands in the same queue from executing until the
                 current one's time is reached. So commands must be sent
        in order
                 (100, then 120, 140 ...). Second, the queue has finite
        length
                 and if too many commands are sent it will backup into
        the host.

                 The TwinRX frequency hopping example will be a good
        reference
                 for you to look at. It implements a different strategy
        where
                 only one channel is used to receive and the second
        channel is
                 used as a secondary LO source, but its inner loop shows
        how to
                 use burst receiving and timed commands to have sample
        accurate
                 timing and do a precise sweep across a list of frequencies.

                 Regards,
                 Derek

                 On Mon, Jun 4, 2018 at 8:40 AM, Fabian Schwartau via
        USRP-users
                 <usrp-users@lists.ettus.com
        <mailto:usrp-users@lists.ettus.com>
        <mailto:usrp-users@lists.ettus.com
        <mailto:usrp-users@lists.ettus.com>>
                 <mailto:usrp-users@lists.ettus.com
        <mailto:usrp-users@lists.ettus.com>

                 <mailto:usrp-users@lists.ettus.com
        <mailto:usrp-users@lists.ettus.com>>>> wrote:

                      Hi,

                      thanks for the great answer.
                      One more question: Is it possible to send multiple
        commands for
                      different times right after each other? So for
        example if the
                      current time is 100, I execute the code you
        provided for
                 120, 140
                      and 160 at once without waiting for the command at
        120 to
                 be executed.

                      Best regards,
                      Fabian


                      Am 03.06.2018 um 12:44 schrieb Marcus Müller:

                          Hello Fabian,

                          the issue can be overcome using what we call timed
                 commands – simply
                          tell your USRP to tune that LO at time X, and
        it'll do
                 exactly that!

                          A bit of example code:

                          //we will tune the frontends in 500ms from now
                          uhd::time_spec_t cmd_time = usrp->get_time_now() +
                          uhd::time_spec_t(0.5);

                          //sets command time on all devices
                          //the next commands are all timed
                          usrp->set_command_time(cmd_time);

                          //tune channel 0 and channel 1
                          usrp->set_rx_freq(1.03e9, 0); // Channel 0
                          usrp->set_rx_freq(1.03e9, 1); // Channel 1

                          //end timed commands
                          usrp->clear_command_time();

                          You can also instruct the RX streamer to start
                 streaming at a
                          specific
                          time, so that you either know beforehand, at which
                 sample count the
                          tuning happened.
                          Alternatively, the rx_metadata coming from the
        USRP
                 contains
                          timestamps
                             of the first sample in the sample packet,
        so you can
                 use that to
                          calculate at which sample the tuning happens.

                          Best regards,
                          Marcus

                          On Sun, 2018-06-03 at 11:35 +0200, Fabian
        Schwartau via
                 USRP-users
                          wrote:

                              Hello everyone,

                              I have a question about frequency hopping in a
                 synchronized
                              scenario.
                              I
                              have two USRP X310, each equipped with two
        TwinRX.
                 The LOs are
                              generated
                              by one of the TwinRX and are distributed
        to all the
                 others (even
                              across
                              the two motherboards). 10 MHz and 1PPS are
        also
                 coming from
                              a single
                              source. Then I use the "unknown PPS"
        method to sync the
                              ADCs. This
                              works
                              perfectly.
                              Now I listen to a single frequency on all
        channels and
                              change this
                              frequency frequently. I would like to hop
        the frequency
                              every 20ms or
                              faster. In order not to loose the ADC
                 synchronization, I start a
                              continuous stream and switch the frequency
        while
                 receiving. This
                              works
                              in principle, but I am not able to
        identify at which
                              frequency the
                              data
                              that currently comes in was recorded. I
        tried using a
                              constant time
                              from
                              setting the new frequency to when I assume
        the new
                 data to
                              be at the
                              new
                              frequency. But even with a timeout of
        ~50ms the
                 results in data
                              indicate
                              the the delay was not enough in a very few
        cases.
                              I know there is the locked_lo sensor, but
        this also
                 does not
                              help. I
                              guess this is caused by buffers which
        cause a more
                 or less
                              random
                              delay
                              between setting the frequency and
        receiving the
                 data. This
                              depends on
                              CPU load and other things, so it is quite
        random.
                              Is there a way to solve this issue? E.g.
        by embedding
                              information
                              about
                              the LO state in the data. Or defining an
        exact time
                 when to
                              execute
                              the
                              frequency switch, so that I can use the
        metadata
                 timestamp
                              in the
                              receive stream to identify the exact point
        when the
                              frequency was
                              switched (I know that the locking can take
        a few ms
                 - so I would
                              discard
                              the data between the switch and the
        signalling+locking
                              offset). Or is
                              it
                              possible to perform multiple time limited
        captures
                 without
                              having to
                              sync the ADCs again?
                              In an ideal situation I would like the
        FPGA to switch
                              frequency, wait
                              for LOs to lock, take a single shot
        synchronized
                 measurement
                              (~1ms of
                              data), transmit the data to the PC (I am
        using 10G
                 link) and
                              continue
                              with the next frequency. Is that possible
        without
                 touching
                              the FPGA
                              code?

                              Best regards,
                              Fabian

_______________________________________________

                              USRP-users mailing list
        USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
        <mailto:USRP-users@lists.ettus.com
        <mailto:USRP-users@lists.ettus.com>>
                 <mailto:USRP-users@lists.ettus.com
        <mailto:USRP-users@lists.ettus.com>
                 <mailto:USRP-users@lists.ettus.com
        <mailto:USRP-users@lists.ettus.com>>>
        http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
        <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>