USRP Software Radio

cancel
Showing results for 
Search instead for 
Did you mean: 

Trying to make a simple but long narrowband delay line from a usrp-2944R

I'm trying to make a simple 100 msec delay line out of a usrp-2944R.

The signal to be delayed is narrowband complex modulation.

To make it, I butchered the streaming Xcvr USRP example way down. All the dsp is on the fpga. 

With just a simple sinusoid from a signal generator it looks fine on a scope and a spectrum analyzer. No visible distortion or drop outs. Sweeping it on a network analyzer the frequency response is flat as a pancake.

The network analyzer has a time domain transform (which I think is just an inverse FFT) that gives you the impulse response of your system. The impulse response of a delay line is just a delayed impulse and that's just what I see. With every benchtop instrument I use this thing looks like a perfect delay line. But when put in it's application it is somehow corrupting the signal. The radio under test is not sophisticated enough to provide any useful error messages. It just won't connect.

Here's the block diagram (can't post VI's) for the fpga, delay line, and host.

There's not much to it. The sample rate is 100kHz. I'm using a frequency offset to avoid the carrier leakage and manually nulling the ADC DC offset.

Can you see anything here that would corrupt an MPSK signal in a way that would not be visible on ordinary benchtop instruments?

Thanks,

Art

Download All
0 Kudos
Message 1 of 30
(3,168 Views)

art_

 

I want to ask a few clarifying questions to understand the issue better. From what I gathered in your post it seems you're sending a signal into the USRP-2944R, then transmitting the same signal out from the 2944R device 100 ms after the first signal was received, correct?

 

Also, can you confirm that the signal being transmitted from the 2944R looks correct on an oscilloscope and spectrum analyzer but not on the network analyzer? Are you using one of our network analyzers? If so, which model?

 

How are you connecting the 2944R to the oscilloscope, spectrum analyzer, and network analyzer? Is the TX port of the USRP going directly into one of the channels of the scope or analyzer? Is there anything else in the signal path?

 

Patrick O.
Applications Engineering
National Instruments
0 Kudos
Message 2 of 30
(3,097 Views)

> I want to ask a few clarifying questions to understand the issue better. From what I

> gathered in  your post it seems you're sending a signal into the USRP-2944R, then

> transmitting the same signal out from the 2944R device 100 ms after the first signal was

> received, correct?

 

Correct.

 

> Also, can you confirm that the signal being transmitted from the 2944R looks correct on an

> oscilloscope and spectrum analyzer but not on the network analyzer? Are you using one of

> our network analyzers? If so, which model?

 

It looks fine on the spectrum and network analyzer. But the difference in time scales between the modulation and the carrier make it difficult to examine the scope results. It looks fine from a distance (long time scale). I can put a pulsed sinusoid from a signal generator into the device and compare the input and output. They look fine on a long time scale (50 msec/div.) If the signal is being corrupted it's happening on a very small time scale.

The network analyzer is a Keysight  E5071C in time domain transform mode.

The scope is an Agilent 10 GS/s DSO (54852A).

The spectrum analyzer is an Agilent N9010A EXA signal analyzer.

The signal generator is an Agilent E8257D.

I am connecting things directly. Nothing else in the signal paths.

0 Kudos
Message 3 of 30
(3,090 Views)

After going over the VI images you posted initially I had some concerns about how the memory is configured. Can you speak more as to how you configured the memory?

 

Based on the images, it would seem as if you're writing data from both USRP channels (RX0/TX0 & RX1/TX1) into the same memory buffer. If so, this may be part of the problem. I would recommend if you haven't already done so to allocate 2 separate memory items for each of the channels.

Patrick O.
Applications Engineering
National Instruments
0 Kudos
Message 4 of 30
(3,081 Views)

Hi Art,

Thanks for posing the detailed diagram. I can't see any obvious errors; however, I noticed you were down-sampling and then up-sampling ... presumably to optimize your resource usage for the delay line. Could you post your code? This will help immensely.

Thanks!

Frank

0 Kudos
Message 5 of 30
(3,079 Views)

Patrick,

Not sure what buffer you meant. Are you referring to the memory used for the delay line? It is vi defined memory: size is 32k, data type is U32,  implementation is block memory. 1 cycle of read latency, interface A(read) & B(write) use arbitration if multiple requestors only. The "32k delay" subvi has preallocated clone reentrant execution so they shouldn't be sharing the same block of memory (should they?) Interesting though, looking at the Memory Usage it doesn't say anything about block ram consumed. Maybe it's lumped in with "code".

0 Kudos
Message 6 of 30
(3,075 Views)

Frank,

I wish I could post the code but the company won't allow it even when the code is nothing special. I am downsampling then upsampling for the sake of the delay line. At full speed 200MHz * 4 bytes * 2 channels * 100 msec = 160 MB of block ram. I don't think the fpga has that much and I don't think the DRAM bus speed would support so much throughput, though I haven't tried. It would sure simplify the design.

0 Kudos
Message 7 of 30
(3,073 Views)

Hi Art,

Thanks for the detailed explanation. Your reasoning seems sound. Depending upon your signal bandwidth, and other factors, the down-sampling or up-sampling filter may be distorting your signal and causing the Rx not to lock on; however, this is just a guess. If you were allowed to share your code with us privately, that will help us solve the problem more efficiently.

Regarding the other post ... Block Ram ... perhaps you could check the project implementation of the delay line and make sure it is coerced to implement in Block RAM (see pic attached).

Kind Regards,

Frank Raffaeli

Principal RF / Microwave Engineer

 

National Instruments, Mi-Aero SE Americas

0 Kudos
Message 8 of 30
(3,071 Views)

Frank,

It is as you describe, coerced to use block ram.

0 Kudos
Message 9 of 30
(3,061 Views)

Art:

 

The DRAM is more than capable of handling the bandwidth if written correctly.  It would prevent the need for adjusting sample rates and possibly causing issues with your signals.  I'd have to double check but I believe the DRAM is 256 bits wide on that USRP.  You would have to collect 4 samples from each channel and write them into DRAM at once.  You will also benefit from doing a block of writes followed by a block of reads so that your DRAM bandwidth is not killed by all the caching.  This solution is more complicated with getting all the timing correct.  If this is something you want to pursue as an option, let me know and I can provide some more details or even try to write a quick example.

 

Andy Brown

Systems Engineering - National Instruments
0 Kudos
Message 10 of 30
(3,057 Views)