Sync interface - RX Signal Phase Jumps

[kartar]

Hi,
I am using the bladeRF board to sweep a complex sine signal at diferent frequencies ( Steps at 50 MHz). To do that, I am using a sync interface provided by libbladeRF.h. and code similar to the test_sync utitility code. The programm works fine, but somethimes, there are strong phase jumps in the received signal (blue I-phase, red Q-phase). This happens occasionally so I think, it is not the problem of the device initialisation.

phase_jump.png

For the test purposes, I created a minimum example programm, based on the test_sync utility. A signal at the frequency -f and -f + 50Mhz will be transmitted and received, the Samples will be written to the output file. It can be started using the common sync_test command from cmd line :
./libbladeRF_test_sync -s 3000000 -f 1350000000 -c 75264 -i samples.bin -o samples_out.bin

Compared to the original code, the set_frequency() function is called in each iteration to change the BB frequency. The python script I used for signal generation and plotting is attached as well (I used 100 KHz complex sine wave). For measurement purposes, I connected the TX and RX with 20 dB attenuator. I tried to use an axternal signal generator at the frequency of 1400,1 MHz and it seems to be problem of the RX (VCO ?). Sometimes it takes some time, before the issue occurs. Currently I am using the build of the last library version from the git. The device is connected to the 2.0 USB slot on a Ubuntu machine.

Am I missing something? I will appreciate any hints or proposals.

Thanks

[bpadalino]

Interesting plot.

Looks like there is a jump every 256 samples or so?

If you run the library with a higher verbosity, do you get any messages talking about any overflows in the receive chain? When you save off samples, are you saving them to a hard drive, or to some place like /dev/shm?

Brian

[kartar]

Hi,
thank you for your reply.
I made some observations and I can say it is not a problem of the sync interface. I reimplemented my code, to use async interface and it leads to the same results.
I figured out, that :
1) It happens only at desired frequencies. I have never seen this result at 450 Mhz but it happens very often at the frequency of 1350 MHz.
2) Both TX and RX are impacted in the same time. I connected RX to the signal generator and TX to spectrum analyzer. If the RX signal is destroyed, the TX signal is destroyed as well.

What I think is that the VCO don't like some frequencies and don't lock properly.... The only think I do between the calls, excepts the init streams and streming, is that I call the blader_rf_set_frequency function. The question is, is my device the only one with this behaviour... ?

[bpadalino]

Wow that looks interesting.

It definitely looks like the VCO is not locked. So by tuning off by 100kHz, you are able to get a nice clean signal, but 1350MHz is a bad value.

If you run with the verbosity of the library set to 'verbose', what other messages come out? Can you provide the log? That would be very revealing. It might be a bad board!

Brian

[kartar]

Hi,

I attached the log files for both cases. One if the signal looks fine and another, if it is distorbed. The files are txt files, but txt and log is not allowed, so i changed the extension to zip.

What did you mean with the 100 kHz tuning ?

[bpadalino]

The logs look fine. They always find the VCO and seem to lock it.

What are you transmitting in the case when things go bad? Just a vector of 1+0j, or something more complex (no pun intended)?

Brian

[kartar]

Hi Brian,

The signal I used was allways exp(j2*pi*f_offset). I will try the ones but I think the result will be the same. The think is, this happens only at some frequencies and sometimes (I would say 25 % of the cases). Is there any possibility to measure the VCO signal on the board? If yes, I coud check the vco output using the spectrum analyzer...

[bpadalino]

You can probe the analog pins from the DAC on J60 - take a look at the schematic on page 11.

This is before any filtering, so you will see all the images from the sample-and-hold nature of the DAC show up as well.

I recommend using a tone like (1+0j) first. If you see it have a square wave like property to it, then it's not good.

Lastly, what samplerates are you trying to push through the device? For USB2, the sample rates probably won't go much faster than 6Msps without causing issues.

Brian

[kartar]

Hi,
The sampling rate I use is 3MSa/s, with the minimum Bandwidth of 1.5 Mhz this should be the optimal sampling frequency and according to wiki it should be fine.
I measured the DAC output at J60 and it looks fine. The reason is definitively the carrier frequency (VCO). It would be nice, if someone could reproduce my results with other device. I have only one device and I can't make any decision if it is a general device behaviour or a hardware bug in my device.

[bpadalino]

Sorry for letting this thread drop.

Are you still experiencing the issues? Does it only happen on certain frequencies, or all frequencies?

Brian

[kartar]

Hi,
sorry for the late reply. I can't spend all my time hunting down this bug. The issue remains, I know that the lower frequencies (under 1 Ghz) are ok. I will test the width spectrum of frequencies to figure out if all bands are affected.

[xor]

Hi,

I'm rather a newbie to BladeRF but I read the issue and I would like to give my idea of what it could be the cause. Maybe I'm wrong, more experienced users could better judge my opinion.

The phase jump could be provoked by the I=0, Q=0 transmitted betweend the burst of bladerf_sync_tx().
If you're transmitting a 100 kHz sine, you probably will have to calibrate the .bin to end with phase =0, otherwise you will always see phasejumps caused by burst truncation (I=0 Q=0).

Cheers

XOR