LimeSDR Mini FPGA Problem

Projects LimeSDR
1

While installing the FTDI FT601 driver, I ran the test per the instructions from FTDI and it overwrote the gateware plus I think something else important. Since then, I have been unable to get the Mini to function properly or update, and could use an assist.

$ LimeUtil --update
Connected to [LimeSDR Mini [USB 3.0] 1D424D31BCC09B]
Claimed Interface

Programming update failed! : ProgramUpdate not supported


$ LimeUtil --info
######################################################
## LimeSuite information summary
######################################################

Version information:
  Library version:	v17.12.0+dfsg-1
  Build timestamp:	2018-01-12
  Interface version:	v2017.12.0
  Binary interface:	17.12-1

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

Supported connections:
   * PCIEXillybus
   * STREAM
   * uLimeSDR


$ LimeUtil --find
  * [LimeSDR Mini, media=USB 3.0, module=uLimeSDR, addr=24607:1027, serial=1D424D31BCC09B]


$ SoapySDRUtil --find="driver=lime"
######################################################
## Soapy SDR -- the SDR abstraction library
######################################################

linux; GNU C++ version 7.3.0; Boost_106501; UHD_003.010.003.000-0-unknown

Found device 0
  addr = 24607:1027
  driver = lime
  label = LimeSDR Mini [USB 3.0] 1D424D31BCC09B
  media = USB 3.0
  module = uLimeSDR
  name = LimeSDR Mini
  serial = 1D424D31BCC09B


$ SoapySDRUtil --probe="driver=lime"
######################################################
## Soapy SDR -- the SDR abstraction library
######################################################

Probe device driver=lime
linux; GNU C++ version 7.3.0; Boost_106501; UHD_003.010.003.000-0-unknown

[INFO] Make connection: 'LimeSDR Mini [USB 3.0] 1D424D31BCC09B'
[INFO] Device name: UNKNOWN
[INFO] Reference: 40 MHz
[INFO] Init LMS7002M(0)
[INFO] Ver=0, Rev=0, Mask=0
Error probing device: ResetChip() failed
libusb: warning [libusb_exit] application left some devices open

When connecting in LimeSuiteGUI…
[16:44:45] INFO: Disconnected control port
[16:44:51] DEBUG: Claimed Interface
[16:44:53] INFO: Connected Control port: UNKNOWN FW:0 HW:0 Protocol:0 GW:0 GW_rev:0 Ref Clk: 40.00 MHz

Programming via LimeSuite and LimeUtil both fail.

A second LimeSDR Mini functions perfectly when attached to the same computer so I know it’s something on the device itself.

Thanks!

2

Hey! Fixed it!

What I did was recompile the FTDI example apps and ran the streamer example app again. Specifically…
./streamer 4 4 1

Something must have gotten corrupted the first time around, but running it to completion has fixed the issue and now LimeUtil --find shows module=FT601 instead of module=uLimeSDR.

Mystery solved. Hope this can save someone else a bit of time and trouble!

3

Argh! Now I have what I suspect (the video is no longer available) this poster was referring to as “wiggle”: Limesdr Mini wiggle. how do i fix this

Here’s what it looks like in LimeSuiteGUI:

wiggle
wiggle.png2504×1828 844 KB

Here is what the second Mini (the one I didn’t mess up with FTDI stream example) looks like on the same setup, exact same steps:

flat
flat.png2514×1748 630 KB

4

i was the poster of the video.
cleaned up to save some space because my google storage promo was ending.
wasnt sure if youtube was included or mot so i made room just in case.

5

Excellent. Is this what you were seeing and were you able to resolve it?

6

Here’s what it looks like in sdrangel with a strong broadcast FM channel in the center…

wiggle2
wiggle2.jpg2160×1690 923 KB

Besides the wiggle, other symptoms are that it sends a long stream of the single character “L” to the terminal, that it indicates dropping packets even at a very low data rate, and that the whole spectrum is shifted up 30dB or so.

For contrast, here is what the properly functioning one looks like…

flat2
flat2.jpg2708×1744 1.14 MB

7

Don’t laugh, but I’ve stumbled into a fix!

By playing around some more with the example program that caused the issue in the first place, I’ve discovered that running ./streamer 2 2 1 has set things right!

Now, both devices perform similarly and I’m right back where I started! Better lucky than good.

I’ll leave this all here as it may help someone else at some point in the future. Self-inflicted wounds are the worst…