# SetFrequencySXR(782 MHz) - cannot deliver frequency

**URL:** <https://discourse.myriadrf.org/t/setfrequencysxr-782-mhz-cannot-deliver-frequency/2144>\
**Category:** LimeSDR\
**Created:** [20 December 2017 19:12 UTC](https://discourse.myriadrf.org/t/setfrequencysxr-782-mhz-cannot-deliver-frequency/2144 "2017-12-20T19:12:28Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![azanetti](https://avatars.discourse-cdn.com/v4/letter/a/8e7dd6/32.png) [@azanetti](https://discourse.myriadrf.org/u/azanetti)\
**Post date:** [20 December 2017 19:12 UTC](https://discourse.myriadrf.org/t/setfrequencysxr-782-mhz-cannot-deliver-frequency/2144/1 "2017-12-20T19:12:28Z")

</div>

Hello,

using LimeSuiteGUI I ran info an issue trying to set an Rx frequency for channel A at 782 MHz:

_SetFrequencySXR(782 MHz) - cannot deliver frequency_  
_INT: 97 FRAC: 862890_  
_DIV\_LOCH: 2 EN\_DIV2\_DIVPROG: 1_  
_VCO: 6256MHz RefClk: 30.72 MHz_  
_VCOL : csw=0 tune fail_  
_VCOM : csw=0 tune fail_  
_VCOH : csw=0 tune fail_  
_Selected : VCOH_

Trying to set 781 MHz or 783 MHz works fine ! I first ran into the issue while trying to calibrate for the LTE band 28 (758 … 803 MHz) with LimeUtil --cal, so checked with LimeSuiteGUI and got the same error.

After removing **~/.limesuite/LMS7002M\_cache\_values.db** the first LimeUtil --cal gives plenty of errors:  
**LimeUtil --cal --start 758e6 --stop 803e6 --chans=ALL --dir=RX 2\>&1 | tee cal\_LTE\_B28\_758M\_803M\_chan\_ALL\_dir\_RX.txt**  
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@  
@@ Calibrating for freq = 782 MHz  
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

Error tuning (skipping): SetFrequencySXR(781.5 MHz) - cannot deliver frequency  
INT: 97 FRAC: 794624  
DIV\_LOCH: 2 EN\_DIV2\_DIVPROG: 1  
VCO: 6252MHz RefClk: 30.72 MHz  
VCOL : csw=0 tune fail  
VCOM : csw=0 tune fail  
VCOH : csw=0 tune fail  
Selected : VCOH

Error calibrating (skipping): MCU working too long 114  
SetFrequency using cache values vco:1, csw:192  
Error calibrating (skipping): MCU working too long 114  
SetFrequency using cache values vco:1, csw:192  
Error calibrating (skipping): MCU working too long 114

If I run again, the error disappears thanks to the cached values, but is it really working ?  
**LimeUtil --cal --start 758e6 --stop 803e6 --chans=ALL --dir=RX 2\>&1 | tee cal\_LTE\_B28\_758M\_803M\_chan\_ALL\_dir\_RX\_cached.txt**  
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@  
@@ Calibrating for freq = 782 MHz  
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

SetFrequency using cache values vco:2, csw:0  
Error calibrating (skipping): MCU working too long 114  
SetFrequency using cache values vco:1, csw:192  
Rx calibration: using cached values  
SetFrequency using cache values vco:1, csw:192  
Rx calibration: using cached values  
SetFrequency using cache values vco:1, csw:192  
Rx calibration: using cached values

_(MCU working too long is another topic)_

\*ware information:  
**pi@raspberrypi3:~ $ LimeUtil --info**  
######################################################

## LimeSuite information summary

######################################################

Version information:  
Library version: v17.12.0-gd352c002  
Build timestamp: 2017-12-19  
Interface version: v2017.12.0  
Binary interface: 17.12-1

System resources:  
Installation root: /usr/local  
User home directory: /home/pi  
App data directory: /home/pi/.local/share/LimeSuite  
Config directory: /home/pi/.limesuite  
Image search paths:  
- /home/pi/.local/share/LimeSuite/images  
- /usr/local/share/LimeSuite/images

Supported connections:

- PCIEXillybus
- STREAM
- uLimeSDR

**pi@raspberrypi3:~ $ LimeUtil --make**  
Make device  
Reference clock 30.720 MHz  
Device name: LimeSDR-USB  
Expansion name: UNSUPPORTED  
Firmware version: 4  
Hardware version: 4  
Protocol version: 1  
Gateware version: 2  
Gateware revision: 12  
Gateware target: LimeSDR-USB  
Serial number: 0x9060b00491f29  
Free connection… OK

Are those errors for real ? Is there any misbehavior to expect ? Or below optimal RF performance ?  
Are some frequencies actually not tunable ?

---

<div class="post-metadata">

**Author:** ![andrewback](https://avatars.discourse-cdn.com/v4/letter/a/22d042/32.png) [@andrewback](https://discourse.myriadrf.org/u/andrewback)\
**Post date:** [21 December 2017 06:43 UTC](https://discourse.myriadrf.org/t/setfrequencysxr-782-mhz-cannot-deliver-frequency/2144/2 "2017-12-21T06:43:27Z")

</div>

AFAIK the calibrations database should not be used any more and gives bad results. @joshblum, perhaps you could just confirm.

---

<div class="post-metadata">

**Author:** ![joshblum](https://yyz2.discourse-cdn.com/flex034/user_avatar/discourse.myriadrf.org/joshblum/32/18_2.png) [@joshblum](https://discourse.myriadrf.org/u/joshblum)\
**Post date:** [28 December 2017 21:58 UTC](https://discourse.myriadrf.org/t/setfrequencysxr-782-mhz-cannot-deliver-frequency/2144/3 "2017-12-28T21:58:55Z")

</div>

Early on I implemented the basic DC IQ calibrating sweeps and caching. The self calibrations based in the MCU have seen a tremendous amount of growth and improvement with the project, and including calibrating many parts of the LMS7 besides DC/IQ corrections. SoapyLMS runs the self calibrations when the stream is activated and I dont think the caching serves a role anymore and should be removed in a future release entirely.