Yes. Almost every command can be made timed on the X3x0s. On Wed, Jun 20, 2018 at 6:17 PM, Felipe Augusto Pereira de Figueiredo < zz4...@gmail.com> wrote:
> Many thanks Derek, I think it worked! > > Is it also possible to schedule gains to be applied into the future? > > Kind Regards, > > Felipe Augusto > > On Tue, Jun 19, 2018 at 6:24 PM, Derek Kozel <derek.ko...@ettus.com> > wrote: > > Yes, I believe all of those commands are exposed in the C API. > > > > For instance, > > https://github.com/EttusResearch/uhd/blob/maint/ > host/examples/rx_samples_c.c#L175 > > > > If you have the ability to use the C++ API for your application I would > > generally recommend that as it is the native API for UHD. The C and > Python > > APIs are derived so sometimes do not follow the most idiomatic > conventions > > of the language. Also the C++ API has the most functionality as not all > > functions and classes are available in the derived APIs. > > > > Regards, > > Derek > > > > > > On Tue, Jun 19, 2018 at 5:10 PM, Felipe Augusto Pereira de Figueiredo > > <zz4...@gmail.com> wrote: > >> > >> Dear Derek, thanks! > >> > >> Last question, are there any commands in the C API that do the same as > >> the following ones? > >> > >> //we will tune the frontends in 100ms from now > >> uhd::time_spec_t cmd_time = usrp->get_time_now() + > uhd::time_spec_t(0.1); > >> //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(); > >> > >> Kind Regards, > >> > >> Felipe > >> > >> On Tue, Jun 19, 2018 at 4:52 PM, Derek Kozel <derek.ko...@ettus.com> > >> wrote: > >> > Hello Felipe, > >> > > >> > The oscillator will *start* tuning at the time stamp you specify. You > >> > will > >> > have to characterize the settling time for your frequency hops and > >> > schedule > >> > the tunes in advance of when you need to be at the new frequency. > >> > Depending > >> > on what frequencies you are moving between and which daughterboard you > >> > are > >> > using the settling time changes. It is important to note that timed > >> > commands > >> > are executed in the order the are issued, not in chronological order, > so > >> > you > >> > must issue them in chronological order for to get the expected > behavior. > >> > > >> > Regards, > >> > Derek > >> > > >> > On Tue, Jun 19, 2018 at 3:45 PM, Felipe Augusto Pereira de Figueiredo > >> > <zz4...@gmail.com> wrote: > >> >> > >> >> Dear Derek, thanks for your prompt reply! > >> >> > >> >> I'm using an x310. > >> >> > >> >> Just to clarify, I want to make sure that the frequency I'm setting > is > >> >> only valid and guaranteed for that specific starting point (the > >> >> timestamp into the future). Right now, when I send just the time > >> >> command and change the frequency for the next packet I see with the > >> >> spectrum analyser that the packets do not have the right frequency, > >> >> instead, they are spread over the spectrum as the oscillator might be > >> >> still under configuration, calibration, etc. > >> >> > >> >> Therefore, I hope that with the timed commands I will be able to have > >> >> a better control over freq/time resources. > >> >> > >> >> Thanks and Kind Regards, > >> >> > >> >> Felipe > >> >> > >> >> On Tue, Jun 19, 2018 at 4:37 PM, Derek Kozel <derek.ko...@ettus.com> > >> >> wrote: > >> >> > Hello Felipe, > >> >> > > >> >> > Yes it is possible. What USRP are you using? Some, such as the B200 > >> >> > and > >> >> > E310 > >> >> > cannot set the frequency using timed commands as the tuning is done > >> >> > by > >> >> > the > >> >> > RFIC rather than the FPGA. There is a small example of tuning in > the > >> >> > manual. > >> >> > http://files.ettus.com/manual/page_sync.html#sync_phase_lo > >> >> > > >> >> > And a longer program using timed commands in the examples. > >> >> > > >> >> > > >> >> > https://github.com/EttusResearch/uhd/blob/maint/ > host/examples/test_timed_commands.cpp#L74 > >> >> > > >> >> > The TwinRX fast frequency hopping example does not show the use of > >> >> > timed > >> >> > commands for changing the local oscillator frequency, but does show > >> >> > very > >> >> > efficient burst reception. > >> >> > > >> >> > > >> >> > https://github.com/EttusResearch/uhd/blob/maint/ > host/examples/twinrx_freq_hopping.cpp > >> >> > > >> >> > Regards, > >> >> > Derek > >> >> > > >> >> > > >> >> > On Tue, Jun 19, 2018 at 3:15 PM, Felipe Augusto Pereira de > Figueiredo > >> >> > via > >> >> > USRP-users <usrp-users@lists.ettus.com> wrote: > >> >> >> > >> >> >> Dear All, > >> >> >> > >> >> >> I've seen that with the gnuradio API it is possible to set a > >> >> >> frequency > >> >> >> and time in the future for a bursty transmission. With that > feature > >> >> >> it > >> >> >> is possible to implement frequency hopping without any big > trouble. > >> >> >> > >> >> >> I'd like to know if the same is possible with the UHD API, and if > >> >> >> so, > >> >> >> how can I do that? One example would be great. > >> >> >> > >> >> >> Thanks and Kind Regards, > >> >> >> > >> >> >> Felipe Augusto > >> >> >> > >> >> >> _______________________________________________ > >> >> >> USRP-users mailing list > >> >> >> USRP-users@lists.ettus.com > >> >> >> http://lists.ettus.com/mailman/listinfo/usrp-users_ > lists.ettus.com > >> >> > > >> >> > > >> > > >> > > > > > >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
