Like I wrote above, if you need both frequency and time synchronization during operation, you have to implement time synchronization based on 1 PPS signal fed to GPIO pin on your own, as noone else has shared the code implementing such funcionality so far.
Or, if you don’t need automatic time synchronization during operation, you can estimate time offset between samples from both devices later, during data processing (e.g. before receiving actual signal of interests, feed the same known signal into RX inputs of both devices and calculate cross-cortelation functions of samples received from both devices and known signal pattern, in order to extract relative time offset between two devices).
I am trying to receive on both the channels of the LimeSDR and am using a USRP Source block in GNURadio with number of channels set to 2, as suggested above. I also understand the limitation of the board in that the two receive frequencies cannot be more than 60 MHz or so apart. My flowgraph in GNURadio is below:
But the two FFT sinks capture the signal for CH1 rather than their respective channel freqs, even after trying with low pass filter blocks in between. Interestingly, this works even if I remove the antennas connected to either channel, which means there definitely is an issue somewhere with the source block.
I also tried the same in Pothos Flow using the supported SoapySDR source block, as shown:
But, alas, same result. Not sure if this source block is also correctly implemented to support the multiple input feature of LimeSDR.
I then went into LimeSuite and checked the “Enable MIMO” checkbox at the top of the interface and kept the configuration to its default settings, but still no luck. Anyone got any solution for this? If it’s LimeSuite related, a walkthrough of the steps needed to configure the suite properly for multiple Rx on LimeSDR to work would be great, or even the .ini file itself. Thanks in advance.
Hello, I’ am new to LimeSDR and GNURadio, but I am facing the same problem. I try to set up a GNURadio flowgraph with an Osmocom Sink with 2 channels with different frequencies. The result is the same as described above. Unfortunately i read in the lms7_api_quick_start_guide.pdf from the /docs folder, that this is not supported in LMS7. In 3.3 Example 3: dualRXTX it says “Note that setting different frequencies for the first and the second channel is not
supported as LMS7 uses single oscillator for both channels.”
Does that mean in the next LMS version it could be supported or is it not possible due to restrictions of the LimeSDR board? Thanks in advance.
In case of most 2x2 MIMO SDRs like LimeSDR or USRP B210 you actually got single TX PLL and single RX PLL, which means that RF frequency of both TX channels will be the same (let’s denote it as f_tx_rf) and RF frequency of both RX channels will be the same (let’s denote it as f_rx_rf).
However, you can introduce different digital frequency offsets for these channels, ending up with:
f_tx_ch0=f_tx_rf + f_tx_digital_ch0
f_tx_ch1=f_tx_rf + f_tx_digital_ch1
f_rx_ch0=f_rx_rf + f_rx_digital_ch0
f_rx_ch1=f_rx_rf + f_rx_digital_ch1
Thanks to that you can transmit/receive at two different frequencies. Sadly, as far as I know, such digital frequency offsets cannot be provided in Osmocom Sinks/Sources. So if you need that, you have to use USRP Sinks/Sources instead.
You should also know that these digital frequency offsets are actually limited by the sample rate.
So it looks like you got two different UHD versions installed (possibly one from repository and second compiled from source?). Such software versions mixing is not advised, and could easily lead to many problems. So at first I would try installing it only once on a fresh OS.
Thanks for the reply. I will do that next. I tried to use the serial instead of the address to identify the device (as described in the documentation of the block) and it does not work either (no error but no device found).
Thank you for your help again @ccsh. It is kind of working now. I got signals with different frequencies on TX channels 0 and 1 now. The frequency on the channel with the DSP offset is a little off and the signal quality is trash, but that is another issue. I am using the uhd.tune_request(freq, lo_off) function from the block documentation.
