05-29-2013 12:26 PM
I'm working on an application that uses a stepped frequency modulation, where the system dwells on a single frequency for a specified amount of time, collects data at that frequency, and then moves onto the next frequency and repeats the process. Our current hardware was a good proof-of-concept, but the dwell times are too long for the application, so we are moving over to the USRP.
We need to have the transmitter and receiver synchronized as they step through the frequencies together. So when the transmitter is sending a signal at frequency 1, the receiver should also be operating at frequency 1 so that our data is collected correctly.
We're currently considering two options:
Option 2 came up because of concerns about crosstalk seen in some previous experiments using a single USRP to transmit and receiver.
Does anyone have any information as to which approach might be better?
Thanks,
David
05-29-2013 05:12 PM
Hello David,
The key thing to consider here is how much cross-talk your system can handle.
There's a 20dB isolation between the TX and RX ports on the USRP. That is your RX will always see your (TX-20dB)
If your application can handle such cross-talk, then you should be good with using one USRP.
05-30-2013 08:36 AM
Thanks for the insight on the crosstalk issue.
A more important issue is the timing between changing the TX and RX frequencies in software. Ideally, this should be done simultaneously. Is this something that we could do on a single USRP?
If the TX and RX frequencies cannot be changed simultaneously, is there any guarantee of having a fixed delay between changing the TX and RX frequencies? We could probably tolerate a fixed delay, for example by ignoring the data collected in the first and last X points at each frequency.
Thanks,
David
06-03-2013 04:05 PM
Using the NI USRP driver you will be able to simulataneously send the frequency change command to both TX and RX whether you are using one USRP or Two.
The difference in time between the TX and RX should be negligible especially if you are using the same USRP.
You can also choose to insert a fixed delay either in your code or, as you mentioned, just ignore the first set of data. The NI USRP driver will give you the ability to get the timestamp on each collected sample.