Dead spots at 645MHz and 321MHz

Projects LimeSDR
1

Hi,

I have the LimeSDR Mini generating 6MHz wide QAM256 cable TV channels… testing setting the transmit center frequency from 57MHz to 999MHz.

If I select a frequency from 641MHz to 649MHz the LimeSDR Mini doesn’t output anything (no channel power).

If I select a frequency from 320MHz to 323MHz the LimeSDR Mini has similar symptoms. At 323MHz I can see some channel power but not across the full 6MHz bandwidth.

If I set any other center frequency in the 57MHz to 999MHz range I see channel power.

Edit - it looks like there might be a dead spot at 161MHz as well. 161MHz * = 322MHz, 322MHz * 2 = 644MHz.

2

I ran a sweep test with 1MHz steps. The modulation is QAM256 and I am measuring the channel power over 5.3MHz width.

Dead spot at 161Mhz.
Dead spot at 320-324MHz and 326MHz. 325Mhz reads ok for channel power.
Dead spot at 641-649MHz and 652-654MHz. 650-651Mhz reads ok for channel power.

3

I ordered another LimeSDR Mini to see if it is a bad board or a systematic fault.

4

I ordered another 9 so I have 10 units total to test with.

Problem confirmed, and I was able to reproduce with LimeSuiteGUI.

The VCO H/M/L bands have some overlap and it LimeSuiteGUI seems to switch back and forth as to which band it chooses for a given frequency. When selecting a problem frequency the TX calibration test fails with “weak signal”. Manually switching the VCO H/M/L band fixes the problem.

It is unclear if the band ranges are too inclusive or there is something going on which results in part of the valid VCO range being unusable.

Unrelated, 1 of the 10 boards failed testing with poor TX SNR in the 750MHz to 1GHz range (not tested above 1GHz). Will RMA that board.

5

Question for LimeMicro - is there a way from GnuRadio/python to force the VCO band and/or override the VCO register?

6

Testing at 100MHz - no VCO overlap for TX (must be VCO H band).

Board will calibrate when hot. Fails calibration with “weak signal” when cold.

7

I wrote a very simple python script that steps through every frequency from 56MHz to 1000MHz in 1MHz steps and simply invokes set_center_freq() followed by calibrate() to have the LimeSDR Mini self check that frequency.

All 10 units fail this test. 2/10 boards almost work and will sometimes pass the test. Most boards fail specific frequencies. A few boards fail badly.

If you have a LimeSDR Mini try running this test…

https://download.silicondust.com/tmp/test.py

  1. Launch a GNU Radio Command Prompt
  2. Run: python test.py
  3. Look for “failed” on any line as it scrolls through
8

More detailed analysis of each unit - 3 of the 10 have significant problems…

Serial # 1D53ADB0FDCB28: Poor TX signal-to-noise above 750MHz, “CGEN tune failed”, “SXR tune failed”, “SXT tune failed”, and “Loopback signal weak” (19-28 failures across 56-1000MHz in 1MHz steps).

Serial # 1D4C29E26EE210: “SXR tune failed” (120-132 failures across 56-1000MHz in 1MHz steps).

Serial # 1D53ADA263761B: “CGEN tune failed” and “SXR tune failed” (23-64 failures across 56-1000MHz in 1MHz steps).

The remaining 7 of the 10 have less dramatic problems…

Serial # 1D53D6126005A9: “SXR tune failed” (5 failures across 56-1000MHz in 1MHz steps).

Serial # 1D53AD061A5FB4: “SXR tune failed” (4-5 failures across 56-1000MHz in 1MHz steps).

Serial # 1D53AE25C4FBDA: “SXR tune failed” (1-3 failures across 56-1000MHz in 1MHz steps).

Serial # 1D53ADF8F64A3C: “SXR tune failed” (2 failures across 56-1000MHz in 1MHz steps).

Serial # 1D53BA744999FC: “SXR tune failed” (1-2 failures across 56-1000MHz in 1MHz steps).

Serial # 1D53ADC81794B0: “SXR tune failed” (0-1 failures across 56-1000MHz in 1MHz steps).

Serial # 1D53AE04851699: “SXR tune failed” (0-1 failures across 56-1000MHz in 1MHz steps).

It is possible these 7 units might be fixable by changing the VCO band selection but this is something Lime Micro would need to change.

9

Hi @jafa,

Do you push “Default” button when using LimeSuiteGUI before trying to tune?

10

The sweep test is done with a GNU Radio python script (link to script above).

When using LimeSutieGUI I hit “reset” to return to the device defaults. The “default” button seems to load very different and likely invalid settings as far as I can tell.

11

Can you elaborate this, please.

12

Sorry, I am not following. I am using GNU Radio to demonstrate the problem (no manual configuration options available), but happy to try anything in LimeSuite to help diagnose the problem.

13

I ordered 2 new boards… both failed the test.py script I posed above. That makes 10/12 that fail every time the test is run and 2/12 which sometimes pass, sometimes fail.

All the script does is ask the board to calibrate itself at frequencies between 56MHz and 1000MHz.

14

Hi @jafa,

We are checking this issue right now. Bear with us, please.

15

Hey @jafa,

PLL locking algorithm was updated in the LimeSuite master branch, could you redo the tests after updating?

16

@Garmus - any chance of a build of the DLLs needed for GnuRadio under Windows please… I don’t currently have things set up to compile from source.

17

Progress…

I switched to a Linux machine and compiled the git master LimeSuite and gr-limesdr. (This also meant switching from USB 3.0 to USB 2.0)

That fixed the TX and RX tune errors leaving only the “MCU error 5 (Loopback signal weak: not connected/insufficient gain?)” errors.

I verified that the LimeSDR Mini isn’t transmitting at the problem frequencies by using a spectrum analyzer.

Also interesting, these dead spots are temperature sensitive… the problem goes away then the LimeSDR Mini is cold, and appear when the board self heats.

18

So far I have tested 6 LimeSDR Minis with git master…

5 pass the test when cold and fail the test with “MCU error 5" at specific frequencies when hot. The transmit dead bands when hot are 80MHz, 160-161MHz, 319-322Mhz, and 639-646MHz.

1 fails with “CGEN Tune Failed” at a number of frequencies (no relationship with the dead bands).

I will test the rest of the boards tomorrow.

19

Tested all 11 boards I have here…
10 pass the test when cold and fail the test with “MCU error 5" at specific frequencies when hot.
1 fails with “CGEN Tune Failed” at a number of frequencies.

1 board almost passes when hot - took a lot longer to show the problem and only failed at a single frequency when it did.

20

Garmus - can you please release a new build for Windows that incorporates the new LimeSuite master branch fix.

I have verified the PLL fix on Linux but need a Windows build to be able to use these boards in production.

The second problem (deadspots) - I have a workaround using heat transfer material to a metal case cooled by a 36W thermoelectric cooler and a CPU heatsink+fan mounted on top. This keeps the LimeSDR Mini cold enough to avoid the deadspot problem. (Verified on one board - I have ordered more parts to test all 11 boards like this).

The critical thing now is getting the PLL fix released for Windows.