I’m getting started on a project that requires phase coherence between transmit and receive. I’ve been working from the dualRXTX example that came with LimeSuite.
I’ve modified it so that instead of reading test signals and retransmitting them, it produces a series of pulses which are then, through 40dB of external attenuators, connected back from TX into RX.
Dumping the RX samples to a file, I can see the pulses I transmitted. There are a couple of issues though: initially, both the phase and amplitude of the received signal varied dramatically from run to run.
I found Zack’s helpful post here:
that shows how to tie TX and RX to the same PLL. After implementing his suggestion, the amplitude of the received signals are now consistent from run to run, and the phase doesn’t wander about randomly any more, but the phase is still not consistent. It appears as though the signals come back with one of two different phases, which appear to be offset 180 degrees from each other. Is there something else that needs to be configured or reset to make the phase come out the same every time?
A 2nd issue is that when the stream gets started up, there is a burst of output, about 350 ms long that I can’t seem to get rid of. I tried writing a stream of 0’s with wait_for_timestamp set to false before I start receiving the stream but that didn’t help. Any suggestion on how to get rid of this unwanted output? This burst at the stream start happened even with the unmodified dualRXTX.cpp.
antenna.
First, check you are using right antenna, LNAL, LNAW, LNAH. TX1_1 TX1_2.
Then, remind below things. (my opinion)
Although you were setting and using antenna channel LNAL( lower than 2.5Ghz), signal power of direct link from TX to RX is too high, so connecting other antenna might work better (beside your setted antenna : may be LNAW).
It means even if your code set antenna to LNAL, check other antenna. (try to connect antenna LNAW, LNAH)
USB bottle neck.
If you were recording your samples to file…, you need to check sample missing. (USB bottle neck)
When sample rate is high, some sample might be missing while write to file.
(in my case. - only using a 1 rx channel-, 10mhz sample rate was fine, but it depend on your pc’s spec)
(using queue and file write thread would be fine)
Stream buffer bottle neck & switching time from rx stream to tx stream delay.
buffer(send receive) and fifo size for streaming. (receive stream send stream) (Limesuite streamming bottle neck)
I guess… lime suite dosen’t work asynchronized.
It meams that…while you receiving rx stream, you can’t get tx stream. and otherwise also same.
(so switching stream rx to tx in board, takes time, and losing samples in stream buffer…)
(At least, you are not really master of thread, i don’t recommend using rx and tx part with not synchronized threading… when each threads require receive or send rx, tx stream, it probably messed up… )
I recommends you use gnuradio or gui tools first, to check what all you want to do works fine in display graph…
In my case, rx and tx both in one limesdr comes out bad performance( although it works, there are some system delays )…, / 2 rx is fine.
**and your link… LMS7 api is more friendly with hardware. and LimeSuite api is using LMS7
So, most case… you don’t need to set register directly. (it might be need when check loopback function. -limesuite doesn’t have… )
In LimeSuite, there are two main parts. LMS Chip, FPGA Chip.
Lms7 api controls LMS chips directly with registers.
LimeSuite api control them with UI using LMS7 library
Thanks for the response. I have checked the antenna selection, and am pretty sure there is no problem there. The output I stream on TX can be seen clearly on the RX channel, so I don’t think there is any problem with the antenna selection. As I mentioned, I included 40dB of external attenuation between the TX and RX channels.
I was only writing the first 5% of the samples to disk, I’m pretty sure there wasn’t a USB bottle neck problem. I did try this with a much lower sample rate (1MHz) and saw the same behaviour.
My issues here are:
Using the supplied dualRXTX example program unmodified (well, except for the frequency), about 350 ms of rf is transmitted before the tx stream is transmitted. This is seen by connecting the TX output to an oscilloscope.
when receiving transmitted signals, they come back with one of two different phases, 180 degrees different from each other.
Have you found a solution for this problem? I am struggling with the same issue.
Also, I have run some tests toogling gpios between sending streams and receiving streams and I noticed that the time it takes to send (or receive one stream) varies a significant ammount between consecutive streams. How can one have a more direct control of such timings, in order to precisely send and receive a stream in a time scale? I assume this must be FPGA related.
@Zack, @andrewback, @ricardas (sorry I didn’t know which one of the team to tag): do any of you has a hint about these problems? Thanks!
Not the most expert person on PLLs, but I believe that they typically lock on an “edge” event so it is usual for simple PLLs to lock at 0 or 180 degree.
I’ve found that the timing issues become much better behaved if you set your transfer buffer size to be equal to an integer multiple of the native packet size (for the packed 12 bit integers, that’s 1360). So set your buffer size to a multiple of 1360.
