Sounds like a bad LED or solder joint. If the LED package green diode isn’t actually connected, no lamp could mean you’ve got PLL lock. Voltmeter across the unpopulated 0.1" through-hole should show a change in polarity depending on PLL lock with your GPSDO.
I’d just stick a replacement LED into the through-hole pads to get a lock indicator; the SMT part is in a pretty tight spot for rework.
Good idea to check if it’s actually locked on Ext REF with LED off. Besides this LED going green is there any other way to determine it’s running on external clock? Tnx.
I don’t know if there’s any way to tell, other than the LED indication, that the LimeSDR is running off the external clock. As an aside: I was trying to form a reply, and realized I don’t understand how providing a [presumably more stable] external reference clock affects sampling of RF signals. The reason I got this GPSDO was to gain improved frequency stability, over the +/-2.5ppm of the LimeSDR VCTCXO. And this, in turn, to improve the ability of OAI to sample LTE, GSM frames.
@Zack, how does providing an external clock improve/degrade the ability of an SDR to be used as an LTE air interface, for example? Does it affect the ability of the radio to tune signals, or does the gateware somehow fall back to the internal clock source if an external reference isn’t available or is mistuned?
I’d love to have a sweep generator to see how tuning behavior changes, when I sweep from e.g. 9MHz to 11MHz, while the ADF4002 is tuned to center freq 10MHz. Will experiment using osmocom osmo-bts-trx - manually sweep the refclock in a band around 10MHz while placing a call to another phone.
@avahilario – quick question - when you run it on 10Mhz REF IN (Green LED) and you launch Gqrx does it say 10 Mhz on this line or still 30.72Mhz? Tnx!
gr-osmosdr v0.1.4-98-gc653754d (0.1.5git) gnuradio 3.7.11
built-in source types: file fcd rtl rtl_tcp uhd rfspace soapy redpitaya
[INFO] Make connection: ‘LimeSDR-USB [USB 3.0] 9070602443038’
[INFO] Reference clock 30.72 MHz
[INFO] Device name: LimeSDR-USB
[INFO] Reference: 3.072e+07 MHz
[INFO] LMS7002M calibration values caching Disable
I get this when I run gqrx from the command line, with the Leo Bodnar connected, Lime in PLL lock:
[INFO] [UHDSoapyDevice] Make connection: ‘LimeSDR-USB [USB 3.0] 9070105C62B09’
[INFO] [UHDSoapyDevice] Reference clock 30.720 MHz
[INFO] [UHDSoapyDevice] Device name: LimeSDR-USB
[INFO] [UHDSoapyDevice] Reference: 30.72 MHz
[INFO] [UHDSoapyDevice] Init LMS7002M(0)
[INFO] [UHDSoapyDevice] Ver=7, Rev=1, Mask=1
[INFO] [UHDSoapyDevice] LMS7002M calibration values caching Disable
I hadn’t checked this before. Just took a look at the source now. It makes sense: GQRX relies on SoapyUHD + LimeSuite. The reference clock settings are hard-coded in LimeSuite, in the function ConnectionStream::DetectRefClk, called by SoapyLMS7::SoapyLMS7.
double ConnectionSTREAM::DetectRefClk(void)
{
const double fx3Clk = 100e6 * 1.008; //fx3 clock 100MHz (adjusted to 100.8 MHz based on measureme
const double fx3Cnt = 16777210; //fixed fx3 counter in FPGA
const double clkTbl[] = { 30.72e6, 38.4e6, 40e6, 52e6 };
....
this->SetReferenceClockRate(clkTbl[i-1]);
lime::info("Reference clock %1.3f MHz", clkTbl[i - 1] / 1e6);
return clkTbl[i - 1];
}
Basically, programs that use the LimeSuite API library and call DetectRefClk use the hard-coded defaults (30.72 MHz reference clock,) it looks like; this includes GQRX.
Not sure which of the Lime folks can point us in the right direction. @Zack, is there a way to force apps that use libLMS7Support.so to use the external clock?
hmm. Maybe we can just patch this file, and add 10MHz to at list of clocks in clkTbl. I’ll take a closer look in a few hours.
I checked LimeSDR USB schematic diagrams looks like TCXO output is always supposed to be 30.72Mhz. On the input side this TXCO can either use DAC, where Ref In Clock is not present, or Phase Detector (ADF4002), where Ref In Clock is present, but both are expected to output 30.72Mhz into TXCO. In case of Phase Detector I assume R and N values are used to transform input Fref (10Mhz, or any other Freq) into output Fvco (30.72Mhz, which we don’t want to change). We can disconnect TXCO all together and inject Ref In directly into the clock path of Clock Buffer but this would require removing R137 and soldering in R147 and, again, the Ref In freq in this case would have to be 30.72 Mhz.
So, I think there is nothing wrong we see 30.72 Mhz reported even with locked external Ref In of 10 Mhz. What I am trying to figure out though is how to confirm whether it is DAC or Phase Detector is producing 30.72 Mhz for TXCO when LED is OFF. According to documented states LED red means DAC is used, LED green means Phase Detector is used but LED off is inconclusive. I am wondering if there is anything else (perhaps some offset I can read?) that would tell me which is used. Tnx.
Correct.
Wrong. DAC produces control voltage, not frequency for TCXO. Just to be able to tune TCXO output frequency a little bit. The same with ADF4002. ADF4002 uses external reference clock, 10MHz for instance. And then it tunes TCXO to produce 30.72MHz.
Hi…in my case i took a look at the LimeSuiteGUI code to figure out how to set the reference clock frequency. It turns out that this involves SPI writes to the ADF4002 phase modulator chip. I extended your code a bit to perform the update from a command line.
Thanks for correcting @Zack. Yes, I see it’s TXCO_VC on the output of DAC and Phase Detector, not the frequency. Do you know if there is a way to read state of either DAC or ADF4002 via LimeSuite or some API call? Tnx.
What is the easiest software method to determine whether the Lime has locked to an external reference? I don’t need to know frequencies, I would just like to reassure a user that the board has locked to the 10MHz reference.
Also, what is the valid range of external reference frequencies?
Hi @SimonG4ELI,
Reference input frequency range is 5MHz - 400MHz, according to ADF4002 datasheet. For RFIN < 5 MHz, ensure slew rate (SR) > 4V/μ.
Currently, there is no way to check if Lime has locked to external reference clock from software. The status is only indicated by on-board LED.
EDIT:
LED description on Wiki:
http://wiki.myriadrf.org/LimeSDR-USB_hardware_description#Indication_LEDs
FPGA LED2 (TCXO control mode):
OFF – TCXO is controlled from DAC (default)
Red – TCXO is controlled from phase detector and is NOT locked to external reference clock
Green – TCXO is controlled from phase detector and is locked to external reference clock
Thanks.
So, in a related question, does the 10MHz REF support work in the MINI as well?
Yes, it will work with 10MHz Ref frequency.
Thank you! I would like to create a command line executable like you have written to set the LimeSDR to sync to an external clock, but I am not sure what to do for the newer version of LimeSuite for the first argument to TransactSPI call. You mentioned this in the bottom of your post.
Edit: A small caveat - the code above only compiles without error with LimeSuite tag v17.10 . You will need to modify the TransactSPI call to use a suitable first parameter, as “addrADF4002” is undefined as used here, in branch 18.0.4.
Since there is no addrADF4002 in GetDeviceInfo() how can I do the TransactSPI call with an updated version of LimeSuite, what would be a suitable first parameter?
Thanks,
Josh