Thomas, I believe I mistyped in my initial response to specify a TX rate change rather than frequency change. It might be more clear if I include some quick pseudocode describing what I'm talking about:
tune_time = usrp->get_time_now() + uhd::time_spect_t(0.1) //Set a > future time to execute commands based on the USRP's current sense of time > set_command_time(tune_time) > //Commands after this point will wait to execute until tune_time > set_tx_freq(<HOP_FREQ>) > //This will be executed at the command time > set_gpio_attr(<HIGH>) > //This will be executed at the command time > clear_command_time() > //Clear the command time, subsequent commands will execute ASAP when > they make it to the radio > sleep(.01) > //Sleep for some arbitrary time. This will roughly > determine GPIO pulse width > set_gpio_attr(<LOW>) > //Return GPIO state to low. This will happen as soon as the radio > gets it, but you could also set it up as a timed command > This approach would not use ATR. It uses timed commands to synchronize your TX freq change with the GPIO state change. There are almost certainly more efficient ways to play with the time setting as to minimize the time between hops, but you get the idea. Based on how you're hopping, you might benefit from changing the tuning policy so that you only change frequency in DSP, rather than retuning the LO: https://files.ettus.com/manual/structuhd_1_1tune__request__t.html Sam Reiter On Tue, Jan 21, 2020 at 8:54 AM Thomas Harder <thomas.har...@oca.eu> wrote: > Thank you Jeff and Sam, > > I found now also the gpio.cpp example. Really helpful to get familiar with > GPIO. > > > > >> To accomplish what you're talking about, I think you'd just need to use > timed commands >>on both set_tx_rate() and set_gpio_attr(). If these are > set to execute simultaneously, the >>GPIO line you set will go high on the > same clock cycle as the LO retune. > > > > In fact in my code which is based on the “tx_samples_from_file” example I > start transmitting my data in the file in the future with tx_metadata_t > time specification and with timed commands I set set_gpio_attr() to the > same point in future. > > But this gives me just 1 output pulse in GPIO what is not sufficient for > my application. > > > > I am transmitting in continuous mode (a fixed modulation in a while loop) > and my center frequency stays fix during the whole transmission whereas > with my data in the file I am modulating the center frequency to discrete > frequencies in the whole bandwidth of 160MHz. I measured a transition time > of the usrp of around 20ns between different frequencies in my modulation. > > *To be able to postprocess my RF signal I would like to have a pulse each > time the tx-frequency is changing.* > > > > As the ATR is just showing if the usrp is transmitting, receiving or idle > it is not really helpful > > And putting set_gpio_attr() in the while loop for my continuous > transmission is slowing down the streaming and causes underruns. > > > > Do you think of any other solution to get a pulse each time the > transmission frequency of the USRP is changing? > > > > Thomas > > > > *From: *Sam Reiter <sam.rei...@ettus.com> > *Sent: *Tuesday, January 14, 2020 6:44 PM > *To: *Jeff S <e070...@hotmail.com> > *Cc: *usrp-users@lists.ettus.com; Thomas Harder <thomas.har...@oca.eu> > *Subject: *Re: [USRP-users] using GPIO output to trigger external RF > switches > > > > Thomas, > > > > To accomplish what you're talking about, I think you'd just need to use > timed commands on both set_tx_rate() and set_gpio_attr(). If these are set > to execute simultaneously, the GPIO line you set will go high on the same > clock cycle as the LO retune. > > > > Sam > > > > > > On Tue, Jan 14, 2020 at 5:59 AM Jeff S via USRP-users < > usrp-users@lists.ettus.com> wrote: > > Thomas, > > > > I am looking at GPIO right now as well. As to your question #2 on > examples, I compiled and am able to run the example I found in the UHD > software: > > > > uhd/host/examples/gpio.cpp > > > > I am able to set individual data lines to experiment with (and eventually > use as a roadmap for my development) using commands like: > > > > ./gpio --dwell 0 --bitbang --ddr 0x00ff --out 0x0055 > > > > which I verified works using a logic analyzer. I eventually want to try > to create a keying loop, but that may take some FPGA control (?). > > > > Jeff > > > > > > *From:* USRP-users <usrp-users-boun...@lists.ettus.com> on behalf of > Thomas Harder via USRP-users <usrp-users@lists.ettus.com> > *Sent:* Tuesday, January 14, 2020 5:07 AM > *To:* usrp-users@lists.ettus.com <usrp-users@lists.ettus.com> > *Subject:* [USRP-users] using GPIO output to trigger external RF switches > > > > Hi, > > I am continuously transmitting a waveform with several RF with 200MSPS > with my USRP X310 (modified code on the basis of “tx_samples_from_file.cpp” > with a waveform in a .dat file). I would like to get a trigger signal from > the USRP when it is changing the tx- frequency which I set in my .dat file. > > Could the GPIO deliver this trigger without changing the image? > > I am using the SRAM image with UHD 3.14.1 > > > > A second question is concerning the GPIO example on > https://files.ettus.com/manual/page_gpio_api.html. > > I copied and paced it in the “tx_waveforms” example just changing the usrp > device handle to “usrp” but when I compiled it and started tx, I couldn’t > measure any tension on PIN 4 and 6 as defined in the example. Are there > more examples how to program the GPIO? > > Thank you, > > Thomas > > _______________________________________________ > 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
