I think something is still very wrong with calibration procedure. I am using GNURadio Companion and when I delete .limesuite/LMS7002M_cache_values.db file or pass ‘cacheCalibrations=0’ to device arguments I am able to get very nice-looking OFDM signal:
Hi @ccsh I am new to this forum, but I can confirm the same bug. When I generate a test signal with a offset 500kHz from the carrier I see the same fault, very large DC leakage when the “.limesuite/LMS7002M_cache_values.db” already exists.
I use the following command to generate the test signal osmocom_siggen -g -35 --sin --waveform-freq=500e+3 -f100e+6 -s5e+6
Hi ccsh and ashley.b,
Thanks for sharing your experiences
In my case, it was used the “kalibrate” application (adapted for UHD) for similar purposes (clocks from local GSM/DCS BS) without successful results for LimeSDR (SoapySDR-UHD and OpenUSRP drivers). You can read about my tests in: LTE signal identification
Probably it is a different issue, although is also using the calibration data stored in “.limesuite/LMS7002M_cache_values.db”, anyway, I’d like also to know about a reliable and repeatable “Calibration Procedure” valid for Tx and Rx in both channels.
I have exactly the same behavior. I’ve also tried on Windows, on Linux, using PyBombs or with everything compiled manually from source (excepted for gnuradio) and got the same results. However, in my case, even though the OFDM spectrum looks great when removing the cache file, I’m not able to decode anything.
I’m doing tests with gnuradio-companion on both the wifi and the dvb-t designs. My testbench is as follows (boards are connected through an SMA cable):
In test cases #2 and #3, using the dvb-t design, sending with the cache file present (and observing the “dirty” curve seen in your “cache1.jpg” image), decoding happens, but reception has a lot of errors. Sending with the cache file removed (and observing the fine OFDM shape as seen in your “ofdmlime.jpg” image), nothing is being demodulated (constellation window shows nothing).
The wifi design shows a similar behavior.
Are you able to demodulate anything? If so, could you share your project or ideas?
Thank you all for responses, good to know that it is still general problem not limited to my use case. I suppose we can just wait and hope for a fix, because this is actually very important matter.
@marsupial67: I did not try to demodulate my OFDM signal yet. I want to try to solve another important issue first: so far LimeSuite seems to be the only way to use second channel at all, I want to try if you can do the same using directly SoapySDR API in a custom c++ app…
As a bump, here is a capture of an OFDM signal transmitted by the LimeSDR. The blue trace is with LMS7002M_cache_values.db erased, the yellow one is with LMS7002M_cache_values.db in place.
We’re able to decode data (albeit with errors) with the yellow trace but not with the blue trace.
Okay, it has been almost a month now since this thread was created and the issue was confirmed by multiple users, yet nobody from Lime team seems to care.
Today I saw following description to @IgnasJ commit on Limesuite github:
calibration cache is not being supported and seems to be buggy, should be disabled by default
Now I have following question: it this only temporary “solution” applied for the time of working on a real fix? Is anybody engaged into this at all? I think we all agree that such calibration is actually crucial feature, because so far none of setting bandwidth, removing DC offset or compensating IQ imbalance seems to work correctly, and doing this in terms of software running on a host machine is not a good way to go because of high requirement on computational power.
Today I have checked that it occurs not only when using GNU Radio, but also when using custom SoapySDR-based application.
I understand that this is not trivial task and don’t expect it to be fixed in few days, but I would like to know if we can hope for it to be fixed some day at all.
Calibration cache has not been working properly since MCU calibrations were introduced. It has always been disabled by default in LimeSuite but enabled in SoapySDR (SoapyLMS). The issue with calibration cache when using SoapySDR keeps coming up and I have encountered it myself multiple times, so I decided to disable it by default. If it has been working good enough for you, you should still be able to use it in SoapySDR by passing ‘cacheCalibrations=1’.
Currently, there are no plans to fix calibration cache. We may decide to fix/reimplement cache if we find out that there are a lot of application for which normal calibration procedures are not fast enough.
Thank you both for a quick response. So it seems like the problem is not the incorrect calibration algorithms but rather some old way of caching their results in a database file which is no longer supported, right? And all we need to get expected results is manually calling LMS_SetLPFBW() and LMS_Calibrate() functions?
If that is correct, I got another question: is there a possibility to manually call these functions from custom SoapySDR-based application? And are they automatically executed e.g. when setting frequency or bandwidth? (this question is probably for @joshblum)
I will be grateful if you could resolve these doubts.
Yes, the issue that I am aware of is related to saving and restoring calibration values to/from database.
I do not know if it is possible to manually perform calibrations in SoapySDR but you should not need to do it unless you want to control when to calibrate. When calibration cache is disabled (or cache database is deleted), SoapySDR will automatically run normal calibration procedures instead of using cache. You should see in SoapySDR log that it performs MCU calibration instead of using cache when you delete database. So that means you should get the same result as with cache database deleted.
Glad to hear someone else can reproduce this problem. I did not have time to look further into this issue.
To me, the next step would be trying an OFDM transmission with Pothos. Even with LimeSuite, if it’s somehow possible. I suspect a problem related to gnuradio-companion’s LimeSDR support.
