Sam, I see want you mean but in my code I set the carrier freq once with set_tx_freq (<carrier_fix>). Then I read the I Q data from a .dat file into the buffer and stream this buffer continuously in a while loop. The frequency hopping is done though my IQ modulation: I = cos(omegan * t) Q= sin(omegan*t) with fixed omega for certain periods like omegan for 0<t<t1 and omegan+1 for t1<t<t2 In this way I am managing to hop between frequencies in the bandwidth of 160MHz around my carrier frequency (cos (omegacarrier*t -omegan*t))with a transition time of around 20ns between different frequencies. But I would like to have a trigger signal, when the USRP is hopping between these frequencies to drive futher external instruments with this trigger output.
Do you have an idea how I could create such a trigger signal? Thomas Harder From: Sam Reiter Sent: Tuesday, January 21, 2020 5:34 PM To: Thomas Harder Cc: Jeff S; usrp-users@lists.ettus.com Subject: Re: [USRP-users] using GPIO output to trigger external RF switches 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 Sent: Tuesday, January 14, 2020 6:44 PM To: Jeff S Cc: usrp-users@lists.ettus.com; Thomas Harder 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
