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

[Frank_R]

Hi Art,

Try removing or adding a bypass to some of the blocks to localize the issue. For example, it appears that the block section: [down-sample ; delay; up-sample] could be bypassed. If that is determined to be effective, then the root cause may be in what Patrick mentioned ... or if an option is to keep full bandwidth (or a less-aggressive down-sampling) and use the delay-line in DRAM, as Andy mentioned.

Kind Regards,

Frank Raffaeli

National Instruments, Mil-Aero SE Americas

[art_]

I ran into some odd behavior when I added bypasses (using case statements) so I commented out different chunks of the code and made multiple fpga images and tried each  with the system under test. The problem is definitely in my delay line. The system under test won't work without delay so we got the wonky delay line this is replacing to stop wonking long enough to put this in line with it. We then started shifting delay from the old to the new. When my delay line is commented out (and all the delay is in the old delay line) everything is fine. Even with it not commented out things work mostly ok with the occasional hiccup as long as the delay is small. But the hiccups happen more frequently as I increase my delay. Somewhere between 70 and 80 msec of delay things stop working altogether. My delay line block diagram is attached. I don't see anything that would degrade with longer delays. How is that even possible?

[art_]

I should have mentioned that the counting loop data type in my delay line is a <+15,15> fixed point number if that isn't obvious.

[AndyBrown]

One small issue that I see that might be contributing to this problem is in the 4-wire hand-shaking.

The decimator block has a 'input valid' block which is currently connected to the interpolator's 'ready for input'.  This is not correct.  Since the clock for this loop is the sample rate, your input is valid on every clock and should be hard-coded to TRUE.  This will mean this block will produce data at its own rate regardless of what is happening downstream.

Your delay logic looks fine as far as I can tell assuming you have a the increment and the subtraction configured for wrapping.  After this block however you will need to put a small FIFO that will mitigate the non-matching timing between the output of your delay (exactly one clock after the output of the decimator) and the required input timing of the interpolator.   The average rates between these blocks are matched but the exact clock each wants input or produces output is not.  The FIFO is used to adjust this.  When your delay code produces a new valid sample it will be written into the FIFO.  Note that the FIFO has a signal that can let upstream modules know that it is not ready for data, however these upstream blocks (decimator and delay) don't have a mechanism to slow down.  So we have to rely on the fact that throughput is steady state.  For the output, the interpolator's 'ready for input' signal gates the ready of data from the FIFO.

[art_]

Sorry for the delayed response but the forums wouldn't let me login until today. Anyway,

please see attached image. Is it what you described? I tried it. Again it works on the bench with test equipment. But when I put it inline with the old system it still corrupts the signal.

[AndyBrown]

That code snippet that you posted looks correct and includes everything I mentioned.  I don't see any issue with your 4-wire handshaking.

Just for my understanding let me try to summarize your issue and you tell me if I'm correct.

• Using your systems with bench top signal generators and analyzers show no degradation in your signal (at least spectrally)
• In the real system you can get it to work with low delays in this new code while using an external solution to apply a base delay
• As you increase your delay there comes a point where the signal appears to break down (although you saw issues occasionally even at low delays)

A few questions:

• Have you used a tap (or equivalent) to look at the spectrum of the signal with your bench top analyzer while it is connected to your system?
• Can you describe what corrupting the signal means?
• Is it possible that it is the changing of the delay dynamically that is causing issues?  (I currently don't see anything in your code to suggest this)

Andy

[art_]

• Using your systems with bench top signal generators and analyzers show no degradation in your signal (at least spectrally)
  Correct
• In the real system you can get it to work with low delays in this new code while using an external solution to apply a base delay
  Not quite. It worked that way with the last iteration (without the fifos). This new version wont work in the system at all.
• As you increase your delay there comes a point where the signal appears to break down (although you saw issues occasionally even at low delays)
  correct

• Have you used a tap (or equivalent) to look at the spectrum of the signal with your bench top analyzer while it is connected to your system?
  Yes. We used a power splitter to watch it on a spectrum analyzer. It looked the same as the input. But on a spectrum analyzer the signal just looks like a blob.
• Can you describe what corrupting the signal means?
  The receiver of the system just can't acquire the signal. It provides no other feedback.
• Is it possible that it is the changing of the delay dynamically that is causing issues?  (I currently don't see anything in your code to suggest this)
  Except in the case where we were shifting delay from the old delay line to the newer, I leave the delay fixed. It's set when I start the vi.

I've been given permission to upload the code to your ftp site, not the forum. Would that help?

[AndyBrown]

Art:

Uploading to the FTP would be a great idea and could really help us see what is going on.  After you upload it send we a PM with file name and password.

Andy

[AndyBrown]

Art:

Since I don't have a way to duplicate your signal I decided to create a version of the code that you sent me that allows me to download a waveform into DRAM via DMA, run it through the algorithm, load it into DRAM, upload it to the host via DMA, analyze it.  I attached a snapshot of my top level FPGA.

On the host I created a chirp waveform (high to low for I, low to high for Q) to make sure there are no effects on various frequencies.  I then tried this for various sample rates and delays (delays ranging from 10 samples to 30k samples).  The resulting analysis showed the delayed waveform looked as expected when compared to a delayed version of the host.  You can see this in the graphs of the included image as the white (host) and the red (FPGA) plots are very similar.  They are not exact because the signal on the FPGA is downsampled, delayed, and upsampled.

Do you have a capture of your signal?  That would be a better test than the chirp.  I can also send you my modified code so that you can try this yourself but you would have to do some tweaks because I had to write for a PXIe-7915 since that was the FPGA board I had handy.

Just a side note, the one issue I initially had was when I did not constrain the frequency range of the chirp based on the lower sample rate.  When it went too high the response was definitely distorted.

Andy

[art_]

You mean a capture of the RF input? The carrier is UHF and the modulation is a few kHz. The timescales are so different I'd only capture 1 or 2 chips. My sample rate is 125 kHz so I should be way oversampled enough that I shouldn't see the distortion you described (if I understand you.)

I could try writing raw data from the ADC and the input of the DAC interface to DRAM then retrieve the data with DMA fifos. Is that possible with the USRP since everything runs at the same 200 MHz clock rate?