Receiving while transmitting: erratic transmission

[fdavies]

I am working on my VNA approximation again. I am having problems with repeatability and noise.

To boil it down, I transmit the same thing twice in succession at the same frequency and get different received waveforms.

I am transmitting a waveform sweep (chirp) from -0.5MHz to 0.5MHz at a center frequency of 400MHz with a sample rate of 2MHz. I have tx connected directly to rx with the gains set so that I get a good, non saturating signal. In order to try to isolate the problem to tx or rx, I also received the signal with a different SDR: RTL2832 w/R820T (Software Defined Radio Receiver USB Stick - adafruit P/N 1497) with a SMA connector places very close (2 mm) to the center pin of the tx SMA connector on the bladeRF board.

The following diagram shows what the blade rx captured to a file (black) as well as what the RTL2832 received (blue) for two different transmissions. The top one is bad, and the bottom one is good.

I do not think that this is external interference: 1) rx and tx connected with SMA cable 2) no sign of interference on receive waveforms right before and after transmission.

Does anyone have any thoughts about what could be causing this?

[bpadalino]

Can you share your code on how you're sending the samples down?

The bad case looks almost like the computer couldn't keep up with the samples.

[bpadalino]

Sorry - I've taken your scripts from the other post and I've used them and recreated what you're seeing. Let me see what I can do.

[bpadalino]

I've used the following two files to reproduce what you're seeing.

setup.cli:

Code: Select all

set samplerate tx 4M
set samplerate rx 8M
set bandwidth 3M
set lnagain 0
set rxvga1 30
set rxvga2 21
set txvga1 -8
set txvga2 20
set frequency tx 400M
set frequency rx 400M

run.cli:

Code: Select all

cal lms
tx config delay=0
tx config file=/tmp/tx_waveform.sc16q11 format=bin samples=131072
rx config file=/tmp/rx_sample.bin n=1M
tx config repeat=2
rx start
tx start
tx wait
rx wait

Trying to debug the problem, it might be that a FIFO is being overflowed or overread somewhere and is losing it's marbles. Given that the RTL SDR dongle gets the chirp from the transmitter just fine, it seems like it's a receive side issue.

Do you agree with that assessment?

[bpadalino]

Can you try something for me and use 300MHz instead of 400MHz and see if you can get it to happen?

[fdavies]

I will try it at 300 MHz.

[bpadalino]

I've used my signal analyzer and I seem to be able to predict if the result will be good, bad or ugly based on what I see there - so it seems like it's primarily a transmit issue.

I've seen 3 different results on the reception: perfect back to back with no phase variation between chirps and very high SNR (as it should be), slight variation in phase between chirps, horrible phase noise which looks absolutely abysmal and as you've noticed.

The frequencies I've seen the latter 2 cases are on the extremes of the VCO's that are internal to the LMS6002D. We may need to tweak the cutoffs for each of the VCO's based on this information to achieve better and more reliable tuning.

I will try this out and see if I can get this a bit more stable.

[bpadalino]

I have reproduced this and found out the issue. Unfortunately, there isn't anything we can do about it from a hardware perspective, but there is a software workaround.

The VTUNE pins are used to tune the VCO's up around 4GHz to around 8GHz, depending on the VCO in question. There are two PLL's inside of the LMS6002D - one for the TX side, and one for the RX side. Lime Micro suggests tuning both TX and RX PLL's off frequency by at least 1MHz. The reasoning for this is due to the PLL's pulling on each other inside the device. If both TX and RX PLL's are enabled, and tuned to the same frequency, there is a chance that they will interact with each other. This is the bad signaling you are seeing. All the digital portions of the device are working properly.

The bad news is that the PLL's characteristics won't change. The good news is that you can tune them to be off by at least 1MHz and you should be able to alleviate the phenomenon completely.

I am sorry I couldn't get this to you sooner. I had been trying all I could to have same frequency full duplex operation without this issue popping up.

Let me know if this makes sense.

[fdavies]

Thanks for all your hard work figuring this out. A 1 MHz offset does not sound too bad, especially as I can easily get 10MHz at a time.

[bpadalino]

No problem. If you still see the issue with the 1MHz offset, please let us know.

[fdavies]

I now have much better results, based on the advise of the inestimable bpadalino. He said that I should transmit and receive at different frequencies if transmitting and receiving at the same time to avoid the tx and rx PLLs interfering with each other. I am transmitting and receiving 6 MHz apart, with a sample rate of 24 MHz.

I got the following results, which are quite satisfactory. Now to buy a directional coupler so that I can measure S11, and make a cavity with a decent Q factor.

spec_1.png

Here is the Octave script that I used:

Code: Select all

%  by fdavies
% based on a file from https://github.com/Nuand/bladeRF/wiki/bladeRF-CLI-Tips-and-Tricks
%  modified
%

GUARD_BAND= 0.5e6;  % separate the frequency sweep zone from the DC spikes
SAMPLE_RATE = 24e6;
NUM_SAMPLES = 131072;  % 
NUM_SECONDS = NUM_SAMPLES/SAMPLE_RATE;

SCAN_WIDTH = (SAMPLE_RATE/4-GUARD_BAND*2);

SCAN_START = 2600e6;
SCAN_STOP = 3600e6;

freq_list = SCAN_START:SCAN_WIDTH:SCAN_STOP;

START_FREQ_RAD = (GUARD_BAND/2) * 2 * pi;  % it will be a complex frequency
STOP_FREQ_RAD = (SAMPLE_RATE/4-(GUARD_BAND/2)) * 2 * pi;

RX_TX_DELTA = SAMPLE_RATE/4;  % to prevent rx PLA and tx PLA mutual interference (pos for rx>tx)

DELTA= (1/2)*(STOP_FREQ_RAD - START_FREQ_RAD)/NUM_SECONDS;
t = [ 0 : (1/SAMPLE_RATE) : ((NUM_SECONDS) - 1/SAMPLE_RATE) ];
tx_signal = (0.8+(0.075/NUM_SECONDS)*t) .* exp(1j .* (START_FREQ_RAD+DELTA.*t) .* t);

save_sc16q11('/media/ramdisk/tx_waveform.sc16q11', tx_signal);

%  set up the bladeRF with a bunch of system command line calls
  %system(["cal lms"]);
  system(["bladeRF-cli -e 'set samplerate rx ",num2str(SAMPLE_RATE),"'"]);
  system(["bladeRF-cli -e 'set bandwidth rx ",num2str(SAMPLE_RATE),"'"]);
  system(["bladeRF-cli -e 'set bandwidth tx ",num2str(SAMPLE_RATE),"'"]);
  system(["bladeRF-cli -e 'set samplerate tx ",num2str(SAMPLE_RATE),"'"]);
  system(["bladeRF-cli -e 'set lnagain 0'"]); % 0 3 6
  system(["bladeRF-cli -e 'set rxvga1 5'"]); % [5, 30]
  system(["bladeRF-cli -e 'set rxvga2 0'"]); % [0, 30]
  system(["bladeRF-cli -e 'set txvga1 -4'"]); %  [-35, -4]
  system(["bladeRF-cli -e 'set txvga2 25'"]); % [0, 25]
  system(["bladeRF-cli -e 'tx config delay=0'"]); %

result=[]; % for when I do many in a row
freq_result=[];
rx_signal=[];

% so, it works by transmitting the sweep signal 3 times while activating 
% the receive.  This is necessary because I do not know how to synchonize
% the transmit and receive well

% so, transmit a frequency sweep from tx_freq+START_FREQ_RAD to tx_freq+STOP_FREQ_RAD
% note that this includes guard bands so it is wider than SCAN_WIDTH
% the part of the frequency sweep that will actually end up in the result is
%    tx_freq+GUARD_BAND to tx_freq+GUARD_BAND+SCAN_WIDTH
% receive it with a rx base frequency that is offset from the tx base frequency

%%%   now for the loop
for fr=freq_list
  % set the transmit and receive frequencies
  tx_freq = fr - GUARD_BAND;
  rx_freq = tx_freq+RX_TX_DELTA;
  system(["bladeRF-cli -e 'set frequency rx ",num2str(rx_freq),"'"]);
  system(["bladeRF-cli -e 'set frequency tx ",num2str(tx_freq),"'"]);
  system("bladeRF-cli -s script_H_1.txt"); % see below for contents of script_D_1.txt
  f = fopen("/media/ramdisk/rx_sample", "r", "ieee-le");
  samples = fread(f, Inf, "int16");
  fclose(f);
  samples_i = samples(1:2:end, :)';
  samples_q = samples(2:2:end, :)';
  rx_signal = (samples_i + j * samples_q);
  % the spectrum will go from -1/SAMPLE_RATE to 1/SAMPLE_RATE in frequency
  spectrum=20*log10(abs(fftshift(fft(rx_signal)))/NUM_SAMPLES);
  trim_start = floor(NUM_SAMPLES/4+NUM_SAMPLES*(GUARD_BAND/SAMPLE_RATE));
  trim_stop = floor(NUM_SAMPLES/2-NUM_SAMPLES*(GUARD_BAND/SAMPLE_RATE));
  trim_width = trim_stop-trim_start+1;
  trimmed_spectrum=spectrum(trim_start:trim_stop);
  result=[result trimmed_spectrum]; % add a chunk to the result
  freq_result = [freq_result fr:SCAN_WIDTH/trim_width:fr+SCAN_WIDTH-(SCAN_WIDTH/trim_width)];
endfor

clf;
rx1=real(rx_signal);
h4=plot(freq_result,result);  %  here is where we see the result
axis([freq_result(1) freq_result(end) -50 30]);
h6=title('Spectrum assembled from pieces');grid on
h7=xlabel('Frequency');
h8=ylabel('dB');
grid on;
%set(gca(),'xtick',min(freq_list):1e6:max);
%set(gca(),'ytick',-30:5:30);
%saveas(h1,"t.png",'png');

% ***************************************
%  this is the script file used by the above
%
% tx config delay=0
% tx config file=/media/ramdisk/tx_waveform.sc16q11 format=bin
% rx config file=/media/ramdisk/rx_sample n=131072
% tx config repeat=3
% tx start 
% rx start
% tx wait
% rx wait
%

[bpadalino]

Awesome! Glad I could have helped. Sorry for the inconvenience it caused, but this is great progress for sure.

Have you thought about windowing and overlapping your results? You may be able to get a better noise floor and possibly see other artifacts?

If you ever make a blog post about this, let us know. This is very cool stuff.