I killed my LimeSDR... maybe

Projects LimeSDR
1

Hello!

So I’ve recently acquired my LimeSDR v1.4s USB-A, did all the testing as per the official information - all checked out well. I then performed the HF EasyFix1 and also a similar modification on the RX2_W following Marty’s experience.
It all worked well and the device checked out ok at this point also.

Then I went a started building my enclosure - I did some hardware work in the box itself, then I stripped the SMT mount LEDs from the device, tinned the through-holes for VCC_INT, Fan and LEDs and called it a day.

The next day I found out that my device does not enumerate in the USB devices list. After doing some preliminary measurements and consulting the schematic, I found out that my VCC3P3 power rail has failed and now measures about 0.95V. The VCC_INT rail also dropped from about 4.6V to 4.1V.

So at this point I suspect that something is loading down the 3.3 power rail, but I’ve visually inspected the board like 20 times and failed to find an obvious cause of this.

Next I’ll try to power the device externally and see what current it draws to see if it is too high or if something else has gone wrong in the voltage regulation.

In the meantime, if anyone has any advice or ideas - I’ll be most welcome. I’m prepared to fiddle around before calling the device a brick because I don’t think I’ve done anything obviously blatant.

Thanks.

ADDED: I tried supplying the power via the external connector. I tried voltages between 5 and 8V and it seems that the VCC_INT rail does not really change - it stays at about 4.1V. The current consumption my power supply reported was about 10mA from 7V and up, while it does not have the resolution to see what’s what on 5V.

I would like to bypass the power supply entirely and supply 4.8V directly to VCC_INT, but I’m not quite sure yet if this is a bad idea.

2

Ok so I mucked around a bit more and supplied 4.8V to VCC_INT directly from the lab supply. The board started consuming about 0.8A and when I hooked it up to the PC, the board got enumerated. I was able to run the LimeQuickTest, and the board passed all the tests.
So that’s good - now I need to find whats wrong with the power source selection circuitry.

P.S. Sorry if this has quickly turned into a monologue thread.

3

Glad to hear that you’ve made some progress and maybe @Zack might have some ideas as to what could have gone wrong.

1 Like
4

Thanks!

Now I’m trying to understand what should the inputs and outputs of the FPF3042 look like to try and assess if I damaged C367 or FR56 somehow. I have a scope, but I must understand what to look for first (like increased ripple on the output rail etc.).
Then I should probably check the VINSEL line just in case.

5

Alright, having read the FPF datasheet, I don’t quite understand where is VCC_INT voltage regulation done? The voltage on the USB jack is ok, but it is already 4.2V on C367, so it comes out of the FPF3042 switch that way. Both when I power from USB and external source.
Looking at the schematic, I cannot really see anything else connected to VCC_EXT though.

Is it a good idea to fit R167?

Thanks in advance for any hints.

6

Hi @OrsonMaxwell,

VCC_INT is not regulated. It should be close to VCC5P0_USB or VCC_EXT, while FPF3042 is power source selector where VCC_EXT takes priority if connected. What is external voltage and what voltage do you get on C367?
From your description it looks like FPF3042 is not working properly. You can supply the board by selecting VCC_EXT of VCC50_USB by soldering R166 or R167. But it is recommended to remove FPF3042.

1 Like
7

Hello, @Zack!

Thank you for taking the time to answer me. What baffled me earlier is the fact that I supplied 7.6V to VCC_EXT pin, and still got around 4.15V on VCC_INT and C367. The same happens both if I supply a different voltage to VCC_EXT (I tried adjusting from 6 to 9V on the PSU without any noticeable change on VCC_INT) and when I just plug in the USB cable. That was what I referred to as “regulating” in my previous post.
So if I understand this correctly now, the voltage does not get regulated between VCC_EXT and VCC_INT rails, and should be supplied as is to the individual regulators for different busses and rails.

Thanks for clarifying the NF resistors business - If I get pressed for time I’ll keep this option in mind. For now I’d like to understand what I broke.

8

Correct.

My guess is FPF3042. Would suggest to remove FR56 and check VCC_INT if it is close to VCC5P0_USB or VCC_EXT. If it is not, then FPF3042 is damaged.

1 Like
9

Yes, having understood the previous point, it makes much more sense to me, thanks. So the working hypothesis is that the FPF3042 chip is damaged and is loading down the power rail somehow similar to a zener diode.
From what I see through my magnifier, the chip looks like it has a silicon package as opposed to a plastic one - maybe I damaged it mechanically by accident when handling the board.

Alright, I’ll find a supplier and try to replace the selector, all the while having a viable workaround solution. Thank you very much for your support!

1 Like
10

This is what is used:
https://www.digikey.com/products/en?keywords=FPF3042UCXCT-ND
Here you can find BOM files where suppliers and product numbers are listed:
https://wiki.myriadrf.org/LimeSDR-USB#Board_Design_Files

1 Like
11

Yeah, I did clone the whole repo before doing the repairs, thanks!

Ok so I removed FPF3042 from the board, jumped R167 (as I only use the device over USB) and it works fine!

I ordered a couple new FPFs, so maybe later I’ll try to solder a new one on - would be a first time fitting a BGA package for me.

Cheers!

12

Glad to hear you that you managed to fix it. Keep us updated on BGA soldering.

1 Like
13

When I fried my power switch, I just bypassed it with a solder blob & run it off of a good quality powered hub (12V powered, not the cheap 5V powered hub). Works great. No problems with TX/RX at all.
Many use a cheap hub that will not supply enough amperage and fail.
I have since bypassed the power switch on my other Lime & it works flawlessly, too.
Actually, I have not had a single issue since doing so. No more reflashing the FX3, no more intermittent issues. Very stable.
Personaly, I would suggest not replacing the switch.

I can actually run both LimeSDR-USBs at the same time on the hub with no issues.

Ed

1 Like
14

I thought about that, it’s just that I’m curious to see if I can get the device back into the shape I bought it in. I don’t plan on using any hubs, and I didn’t have any issues prior to damaging the IC.
But since I damaged it, I thought about putting a small buck converter into the enclosure in case I need to power it via a car battery in the field.

15

Ok so I’ve built my enclosure, but apparently this idea is too good to be true. At least, failures seem to haunt me in this project.

After this topic was done, I’ve been happily using my LimeSDR for some time to listen to broadcast radio (the only thing I’m equipped to receive at my city apartment). All because my SpyVerter unit turned out to be faulty from the factory.

So after 4 more weeks of shipping, I got a replacement and built everything into an enclosure only to find that my LimeSDR would not enumerate as USB 3.0 now. The USB port in my desktop PC, the cable and all of the software are the same (except I cannot remember if there was a Windows update during all this waiting).

The board still checks out ok in LimeQuickTest, and I’m able to run the WCDMA self test using LimeSuite. However, the device no longer negotiates a USB 3.0 connection, so I don’t have access to the full bandwidt, which is very sad, because it is why I upgraded to Lime in the first place.

I tried using 4 different USB 3.0 cables (including the one that worked before), I tried all the USB ports on my motherboard, in my brother’s PC as well as all the ports on my wife’s Dell Latitiude 5590 (which are USB 3.1). Here is what I found:

  • the device never gets enumerated in any of the 3.1 ports - I have one in my PC and three in the laptop;
  • the device gets enumerated as USB 2.0 in some of the USB 3.0 ports on both PCs;

Also I noticed that the VCC internal rail sometimes shows a lower voltage - 4.5 to 4.8V. I tried supplying the power externally with no difference on the USB2.0/3.0 status whatsoever.

I checked the continuity of all 9 USB 3.0 lines from cable male plug to the actual board pins using the previously working cable - the continuity checks out ok as per the standard USB pinout.

I run Windows 10 x64 with the latest drivers installed as per this article as well as the latest PothosSDR binary.

At this point after all the previous power issues and all the soldering involved in the enclosure build, I am now open to all possibilities however stupid they may make me look, and any advice would be very much appreciated as I’ve ran out of ideas to test.

Thanks in advance.

ADDED: I also have access to Arch Linux on my PC, so if there is something specific I could try there, it is possible.

16

Hi @OrsonMaxwell,

It enumerates as USB3 in this case?

Could you share LimeQuickTest log file, please.
What Device manager is saying?

Yes, would be nice if you could share lsusb command output.

17

No, Windows acts like nothing is plugged in at all. Nothing in the device manager as well.

Here it is when I plug into a 3.0 port (was working earlier):

c:\Program Files\PothosSDR\bin>LimeQuickTest.exe
[ TESTING STARTED ]
->Start time: Wed Jul 15 23:57:42 2020

->Device: LimeSDR-USB, media=USB 2.0, module=FX3, serial=0009081C05C12523, index=0
Warning: USB3 not available
  Serial Number: 0009081C05C12523

[ Clock Network Test ]
->FX3 GPIF clock test
  Test results: 19922; 23678; 27434 - PASSED
->Si5351C test
  CLK0: 17555 / 17554 - PASSED
  CLK1: 17555 / 17554 - PASSED
  CLK2: 17555 / 17554 - PASSED
  CLK3: 17555 / 17554 - PASSED
  CLK4: 17555 / 17554 - PASSED
  CLK5: 17555 / 17554 - PASSED
  CLK6: 17555 / 17554 - PASSED
->ADF4002 Test
  Result: 10 - PASSED
->VCTCXO test
  Results : 5112966 (min); 5113105 (max) - PASSED
->Clock Network Test PASSED

[ FPGA EEPROM Test ]
->Read EEPROM
->Read data: 13 02 1A 13 02 1A 02
->FPGA EEPROM Test PASSED

[ LMS7002M Test ]
->Perform Registers Test
->External Reset line test
  Reg 0x20: Write value 0xFFFD, Read value 0xFFFD
  Reg 0x20: value after reset 0x0FFFF
->LMS7002M Test PASSED

[ RF Loopback Test ]
Note: The test should be run without anything connected to RF ports
->Configure LMS
->Run Tests (TX_2-> LNA_L):
  CH0 (SXR=800.0MHz, SXT=805.0MHz): Result:(-13.7 dBFS, 5.00 MHz) - PASSED
  CH1 (SXR=800.0MHz, SXT=805.0MHz): Result:(-14.7 dBFS, 5.00 MHz) - PASSED
->Run Tests (TX_1 -> LNA_W):
  CH0 (SXR=1800.0MHz, SXT=1805.0MHz): Result:(-14.3 dBFS, 5.00 MHz) - PASSED
  CH1 (SXR=1800.0MHz, SXT=1805.0MHz): Result:(-15.8 dBFS, 5.00 MHz) - PASSED
->Run Tests (TX_2-> LNA_H):
  CH0 (SXR=2500.0MHz, SXT=2505.0MHz): Result:(-16.1 dBFS, 5.00 MHz) - PASSED
  CH1 (SXR=2500.0MHz, SXT=2505.0MHz): Result:(-13.8 dBFS, 5.00 MHz) - PASSED
->RF Loopback Test PASSED

=> Board tests PASSED <=

Elapsed time: 3.46 seconds

LimeSuite:

image
image

Device Manager:
image

lsusb -v output:

Bus 001 Device 005: ID 1d50:6108 OpenMoko, Inc. Myriad-RF LimeSDR
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.10
  bDeviceClass            0 
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x1d50 OpenMoko, Inc.
  idProduct          0x6108 Myriad-RF LimeSDR
  bcdDevice            0.00
  iManufacturer           1 Myriad-RF
  iProduct                2 LimeSDR-USB
  iSerial                 3 0009081C05C12523
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x002e
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           4
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0 
      bInterfaceProtocol      0 
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x0f  EP 15 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x8f  EP 15 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
Binary Object Store Descriptor:
  bLength                 5
  bDescriptorType        15
  wTotalLength       0x0016
  bNumDeviceCaps          2
  USB 2.0 Extension Device Capability:
    bLength                 7
    bDescriptorType        16
    bDevCapabilityType      2
    bmAttributes   0x00000002
      HIRD Link Power Management (LPM) Supported
  SuperSpeed USB Device Capability:
    bLength                10
    bDescriptorType        16
    bDevCapabilityType      3
    bmAttributes         0x00
    wSpeedsSupported   0x000e
      Device can operate at Full Speed (12Mbps)
      Device can operate at High Speed (480Mbps)
      Device can operate at SuperSpeed (5Gbps)
    bFunctionalitySupport   3
      Lowest fully-functional device speed is SuperSpeed (5Gbps)
    bU1DevExitLat           0 micro seconds
    bU2DevExitLat           0 micro seconds
Device Status:     0x0000
  (Bus Powered)
18

Talk about bad luck - I resolved to the thought that I had inadvertently damaged the USB chip when soldering, so I went on and ordered another limeSDR only to discover that it was apparently lost in shipping :sleepy:

19

Bad luck indeed :frowning: Responded to your PM and will be in touch with CS to sort out.

20

Ok thanks to Andrew and the guys over at CrowdSupply, my parcel finally found its way to me, and I’m happy to report, that the device checks out alright both before and after all my modifications since I took a bit more care with ESD when soldering this time :sweat_smile:

Cheers!

1 Like