Gain is low when starting from a known-good preset

[martywittrock]

I'm seeing an issue where I have a 'known-good' preset and everything seems to adjust right for frequency, sampling, gain settings, ect, but when I start the receiver the gain seems low. It's not until I adjust the sampling by 1 lower digit that the gain pops back up and noticeably higher, yet the same sampling rate.

[brendanthebig]

I am having the same issue but I can get the gain level back to what I expect by adjusting the LP filter. Even putting it back to the preset level, the apparent gain is still ok. Considering that Marty is adjusting sample rate and I am adjusting LP filter to correct the gain, I think it might have something to do with the dreaded calibration procedure ????

[brendanthebig]

Just a thought...Is calibration performed when a preset is loaded or only when a change is made to the sink or source settings ? Is calibration performed when a stream is started ?

[f4exb]

Hello,

there are two calibrations: LMS_Calibrate and LMS_SetLPFBW. They are done in a single place but in many conditions. LMS_SetLPFBW as the name implies is done only if a change occurs in the LP filter. The main calibration LMS_Calibrate takes place if after all changes have been applied then a change in the clock generator takes place and also systematically in the following cases:

• change to auto gain
• change to any of the gains in manual gain mode and if gain mode is switched to manual
• host sample rate or hardware decimation/interpolation
• change in antenna switch
• change in center frequency
• switch to external clock or back to internal clock

In any case when you start streaming or load a preset all changes are activated hence calibration will take place.

However I don't seem to encounter the problem you describe either on a "cold" start (load preset then start) or "hot" (load preset while the stream is running).

[martywittrock]

Edouard,

I was running my LimeSDR on the HF band (75m and 40m) and I noticed that the gain was very low - to the point that I tried an older version of SDRAngel (3.7.6-1) and from the same presets and what seemed magically my LimeSDR receive signal strength improved greatly over 3.8.3-1. So at the moment I've gone back to 3.7.6-1 since my receive is better. But there is definitely an issue with receive gain with the 3.8.3-1 release. I will try the newest release 3.8.4.7 and see if there's an improvement. but just reporting the gain issue since it is definitely there.

[martywittrock]

Just tried 3.8.4.7 and it seems to be the same - has low gain in receive. I'm using a 5.0 MS/s and LPF at 100 MHz running H=32, S=32, FIR 2.500. There is definitely a difference in receive signal strength between 3.7.6.7 (3.7.6-1) and the prior release 3.8.3.7 and this latest release 3.8.4.7. The two latest releases are acting the same with the low receive signal strength against 3.7.6.7 that seems very much normal running the same receive preset that I've listed here.

[f4exb]

There has been some code changes to do the calibration in the right conditions and this was done according to LimeSDR development team recommendations and I believe this is now correct. I have found no issues related to this code and in fact it is working much more smoothly.

Other than this and equally important are the changes done in the builds particularly the Windows build. Until 3.8.0 this was using LimeSuite 17.09.1 (3.7.8 was still using 17.09.1 this was a mistake) so when running 3.7.6 you are in fact using the LimeSuite 17.09.1 code and in revisions from 3.8.0 and above this is 17.10.0. The 17.10.0 needs the latest firmware (2.11) and you will have to upgrade your LimeSDR to be compatible.

In the next version (3.8.5) LimeSuite will have to be upgraded again to fully support LimeSDR mini (see #100).

[brendanthebig]

I just upgraded my LimeSDR to latest firmware and fpga. Now I can't change freq in sampling device (main and nco) or change LP...Freq is stuck on 0,000,000 and LP filter is stuck on 000,000. Sample rate is also stuck on 0,000,000.

UPDATE...Problem was corrupt zadig drivers...Could not re-install so did a windows system restore. Working again now.

UPDATE 2... I had to downgrade FPGA gateware to 2.10 as I was having random problems with my LimeSDR having above mentioned problem OR not being seen by sdrangel at all. All seems ok now that I have downgraded gateware.

[martywittrock]

I've got a LimeSDR setup now for Linux running on a UDOO Advanced card loaded with Ubuntu 17.10 and compiled/ran the latest release sdrangel_3.8.4-1_amd64_artful.deb on that card and got it working properly once I had all the dependencies determined (LimeSuite, SoapySDR and others). Now that I have a good testing set, I will try an earlier release like I have for Windows to see if there's a difference or not using Linux. I am still of the opinion that there is a receive gain difference with older versions of SDRAngel as compared to the latest release, but I'll work that this evening and let you know how my older compile works...Stay tuned...

[martywittrock]

As much as I hate to say this, there is a gain difference between the versions 3.7.6-1 and the current version 3.8.4.7 using Ubuntu 17.10. I can take my LimeSDR on the latest release and try to tune the 80/75m band (3.5 MHz to 3.99 MHz) at night and it's deaf. I can go back to 3.7.6-1 or use SDRConsole V3.0 on my Windows machine and the LimeSDR looks great tuning in those same bands - I'm seeing signals and the receive activity is correct. the latest version makes my LimeSDR seem 'deaf' no matter that I'm setting the gain controls to maximum.

This is disappointing...SDRAngel was my 'go to' application for receive and transmit for the Lime. I can limp along with 3.7.6-1 forever, but the new features (like the headless design that's emerging) will not be in that version. Despite what the Lime Team has told you how to handle calibration and gain settings, there's something wrong with the latest release of SDRAngel. Even with the latest firmware installed using LimeUtil --update and seeing that the latest firmware is installed in LimeSuite makes no difference for the operation - the Lime still seems deaf. Yet I can take it across the room, plug it into SDRConsole V3.0 and it works great for receive.

What happened?

73 de Marty, KN0CK

[f4exb]

This could be an issue with the analog lowpass filter since on 80m band (~ 3.5 MHz) you are very dependent on it being at ~26.5 MHz from the center of the analog passband if the LO is tuned at its lowest (30 MHz). I noticed that when loading a preset the LP value is not set correctly and remains as it was before. You have to fiddle with the LP filter thumbweels to make it effective. If the LP stays at a relatively low value then the 80m band is way out the filter limits.

I also noticed that the value is the full passband. In the LMS7002M doc it says that the lowest value is 0.7 MHz but the lower limit given by LimeSuite is 1.4 MHz that is in fact +/- 0.7 MHz. It seems LimeSuite does the maths to translate complex lowpass to real lowpass around the center of reception.

Note: it seems to be introduced with this commit

if (doCalibration) ... else if (doLPCalibration) ... should not be an else if but just a if

Note2: the same problem exists on Tx side

[martywittrock]

Edouard,

WOW!!! The 3.8.5 Windows release works WONDERFULLY AGAIN..!! Nice gain in the 80/75m band and well into the 40m band, too..! I haven't tried transmit but will tomorrow. I'm going to switch over to the UDOO card and see if I can compile it for Ubuntu 17.10 and check the performance - it's likely to be the same, but just wondering - More to follow on the Linux compile - stay tuned..!

UPDATE: I started with a usual compile for 3.8.5 for Artful (Ubuntu 17.10) and did not see a difference from the earlier version. So I did a ‘make clean’ and started with a completely new compile. Once it was completed and I did the sudo make install and ldconfig I tried it again and noticed that it seemed dead. So I started playing with the controls and once I adjusted the 30.000 MHz to 40, then 50. and then back to 30 MHz I was able to get good receive as well as I did with Windows out of the chute.Gain in receive seems comparable to what the Windows build is and I’m even able to hear the AM broadcast band very well with this version. Again, seems with Linux that you have to play with the ‘30.000’ (switching it up to 50.000 and then back to 30.000 to make the receive operate normally). Windows doesn’t do this for some reason, but I’m just glad the receive works again. Also I tired transmit and had the same issue - you have to play with the 30.000 (switching to 32.000 and then back) and transmit seems to work great, too…! So while 3.8.5 has some oddities in Linux as compared to Windows, both functions work very well.

73 de Marty, KN0CK

[f4exb]

Cool! so now this can be closed as implemented in v3.8.5