I’m using LimeSuite 17.10.0-PothosSDR-2017.11.26-vc14-x64, and the latest (4 DEC release) firmware and FPGA gateware. I am having an issue getting phase shift corrections to “stick” on my LimeSDR USB HW 1.4, I can make some changes and then click GUI->Chip and then when I release the board from LimeSuite and start GNURadio I still see a significant phase shift between the two RX signals for a 0 degree input difference.
I’m running a signal source into a Mini-Circuits ZN4PD1-63HP 4 way 0-degree hybrid, with two equal lengths of transmission line (matched, from Mini-Circuits) into the RX ports of the LimeSDR. The other two ports on the hybrid are terminated with Z50 SMA terminators.
Can someone walk me through how phase corrections for the RX’s are supposed to be applied from LimeSuite? I’m assuming that it’s the following, please let me know where I go wrong:
Start LimeSuite
Connect to LimeSDR
Chip->GUI
Make changes in the GUI
GUI-> Chip
Disconnect from LimeSDR
Start GNURadio and test.
However when I read Chip-> GUI I don’t seem to see the changes I made. It seems to have some values in that I didn’t place. Please advise me where I’ve gone wrong.
Demonstrating some of my issues: Not only is there a phase offset (shown on the histogram on the bottom, and the RX0 and RX1 waves on the top, but this phase offset seems to be different every time I start the LimeSDR receiving through GNURadio.
Issue of misaligment was raised many times so far. Still no solution was offered. I had to drop my project due to this. LimeSDR team ignores the topic so far.
Oh, that’s really terrible. If this is an unresolved issue that there is no support for, I will be abandoning the hardware immediately. How can this not have been addressed by now? I feel like I’m missing something here, as from looking at the block diagrams both receivers are fed from a common oscillator source so I don’t know how this is happening other than the chip is dropping phase trim values between operations?
@andrewback please tell me that I’ve missed something, or that there is some method to make the front end settings persistent.
I suspect that once you’ve disconnected/reconnected the radio gets reset and you lose any changes made via Lime Suite. There is an ongoing discussion about implementing an LMS7002M/LimeSDR control block in GNU Radio to give access to many more or all of the available configuration options, with perhaps the first thing being the ability to load an ini file generated in Lime Suite.
@joshblum, is there anything you could suggest until this is worked out?
My best guess is ADC misalignment. Resetting of register does not help. Since your demo is in GNU radio maybe someone will take a closer look since it is easy to reproduce. I think it will be useful if you will post sample project.
Also check those topic:
I think this is a common issue you (user application) should solve when you need coherent/aligned carrier phases. To be specific, you need to calibrate the phase offsets between channels before you start using multiple antennae (e.g. beamforming etc.).
The hardware should guarantee the phase offsets do not change over time (or at least change very slowly) once the board is powered on. However, the hardware usually cannot guarantee the fixed phase offsets between two power cycles.
If the above is true, even if you implement the ini file and read the calibration value in GNURadio, you may still get unaligned phases.
To verify that, you can power up the board many times (say 20~50 times), check the phase offsets. (Note that you may power cycle the board in different time of the day / enviroment temperature). If the phase offsets remain unchanged, reading ini file can work. Otherwise you need to calibrate the channels in your application.
One more comment.
Since the two RX channels share a same LO in a single chip, you will probably get a fixed phase offset (Note that the phase offset may slightly change according to frequency and temperature etc.). In this case, you can calibrate via some predefined values in some ini files.
However, if you are using more than two channels (two chips) you need to have your phase calibration in your application.
Just share some measurement result from AD9361 for reference:
I use 4 channels (called A B C D) in my system and channel A B from one AD9361, channel CD from the other. The measured phase offset between A and B (also C and D) is always ~3.1~3.8 degree, but that between B and C are arbitrary values within [0, 360] degree.
The oscillators in the LMS7002M (Rx LO, Tx LO, and ADC/DAC clock) get retuned every time the every time the device is for 1 opened and 2 when its LOs are turned. These are fracN synthesizers and the phases will be random after every retune but fixed in phase between one another. This is an incredibly common paradigm across the SDR community FWIW.
With significant driver changes it might be possible to close the device handles and not power down anything, and on reopen, do not reset or retune any of the configurations. So this isnt a matter of reapplying a .ini file, we cant really even apply the same settings without loosing the relative phase offsets between clocks/LOs – But I dont really know if this would be possible. Its certainly a little dangerous to not properly cleanup a device handle when closing or to not reinitialize when opening. And there might be issues with the USB fifos.
Is it possible to keep the application up? Split it into a client/server model? Apply phase shifting to the sample stream based on channel measurements etc?
FWIW, I wouldnt have thought to use the phase corrections in the TSP this way, but if it works, don’t knock it Anyway if it helps, the set_iq_balance call is gr-osmosdr blocks (which can also be called from python) can apply phase corrections to the TSP. Just pass in a complex number with some phase and 1.0 magnitude.
If the phases were random, but fixed (and remain fixed) in their offset that would be a matter of a quick calibration on start up. That being said, none of the modifications done to the device appear persistant so that complicates things. The phase corrections don’t seem to have a lot of effect in my measurements.
However, what worries me more is that over the period of a minute I watch one channel move over 180 degrees phase relative to the other. The frequency stability looks alright, the phase stability not so much. I’m just downsampling a screen capture video to upload that demonstrates this. Having the phase shift on me so substantially means that I’ve really wasted my time trying to get this hardware working.
UHD source, as using two osmocomm source and trying to set them up for each channel has not worked out for me. That could be my fault in configuration.
Yeah I can live with random phase offsets at startup if I have to, do a quick loopback and calibrate before getting to actual measurement. But the phase actually shifts over time between the two channels quite substantially and that makes it impossible for me to use it for my purposes.
i have the same problem using LimeSDR and Gnuradio, i do a program to measure the phase between the two receivers channels and i use a VCO and splitter to generate the signal. If i measure the phase every second whitout turn off the LimeSDR i see a random phase between the two receiver channels, i thinks is a hardware problem more than software, u can help me to verify this? thanks a lot
Anyway if it helps, the set_iq_balance call is gr-osmosdr blocks (which can also be called from python) can apply phase corrections to the TSP. Just pass in a complex number with some phase and 1.0 magnitude.