In a previous posting, the range of RX LNAW has been described by RicardasVadoklis this way:
LNAW - from 0.1 MHz to 3800 MHz. Gives a noise figure 5-7dB. Usually used for sniffing.
LNAW - has broadband matching up to 2000 MHz.
The LimeSuite API, however, provides a different minimum for LNAW in lms7_device.cpp:
LMS7_Device::GetRxPathBand
case LMS_PATH_WIDE:
ret.max = 3800000000;
ret.min = 700000000;
break;
That’s 700 MHz by my reading. Is there some limitation in the software besides just declaring this that results in this being the minimum the software (or Board) can do? Also, I have a stock LimeSDR with no network modification.
Thanks.
I wouldn’t have expected there to be, but @IgnasJ should be able to confirm.
Hello,
Right now, I can’t remember where exactly those API values came from. They may be for some older board revision.
Looking at the LimeSDR board schematics
(https://github.com/myriadrf/LimeSDR-USB/blob/master/hardware/socket/1v4/Project%20Outputs%20for%20LimeSDR-USB_1v4s_LMS031pad/LimeSDR-USB_1v4s_schematic_r7.PDF)
the recommended ranges are:
LNAL: 700 MHz - 900 MHz
LNAW: 700 MHz - 2.6 GHz
LNAH: 2 GHz - 2.6 GHz
TX1: 30 MHz - 1.9 GHz
TX2: 2 GHx - 2.6 GHz
My thoughts now are that values in API were extended to cover 30 MHz - 3.8 GHz range to make it easier for software to implement some kind of automatic port selection. Anyway, we will look into API values and update them if necessary.
Just to note that the schematics note where peak performance is with the default matching networks, and do not indicate that you could not or should not use these ports with frequencies outside those bands.
Figure 1 of the Optimising LimeSDR matching for HF article indicates that the default network used with LNA_L for 400 Mhz ought to perform well. That does not appear to be congruent with the recommended frequencies above for peak performance. Am I reading this wrongly?
According to Github change tracking it used to be the case that GetRxPathBand was used internally by the Lime API to automatically select an RFE PATH when setting an RX frequency, but that’s no longer the case. Now it’s just potentially misleading to API users.
Also @IgnasJ I cannot find the recommended ranges in the the document you cite. There is a lot of fine print, did I miss them? Thanks.
Andrew
You have to be kidding. Are you now going to limit the lower frequency of the board to 700 MHz + ? The board has worked at 21 MHz with the upconverter and board RF tuned to 30 MHz. I expect that there is some rolloff on the low end, but if it is gradual, it will be OK.
The software limitation is a bug.
Paul
I don’t believe it’s a limitation per se and it’s more to do with automatic antenna selection.
You can find it on page ‘LMS7002M RF1 circuits’ or ‘LMS7002M RF2 circuits’. It is next to each RF port. But like Andrew said, it only shows where the maximum performance of matching networks is. You can use ports outside of those ranges.
Andrew - As in my previous note, and I just searched the LimeSuite Github repository again to confirm, the API no longer uses that method for any automatic selection, which is probably a good thing. The issue is that neither the function name nor comments tell you about the range being returned. Users are left to guess or draw incorrect inferences.
