Replaced HF-modified LimeSDR board is also damaged

Projects LimeSDR
1

Dear Lime Team,

It looks like the replaced LimeSDR board I got from CrowdSupply is also damaged in the very same way as the original, which I have described in details here. With the replaced one, I am still getting errors even when trying to run simple probe command:
SoapySDRUtil --probe

In “RestructureLimeSuite” branch I am getting a lot of “[ERROR] Read(64 bytes) failed” messages, while in “master” branch I got different errors: “version 0, revision 0 gateware mismatch” or “setBandwidth(Rx, 0, 30 MHz) Failed”. The same problems occur when trying to use other apps, like GNU Radio, custom SoapySDR-based app etc.

I have tried different USB cables, connecting the board directly to computer USB 3.0 ports, used different host machines, updating gateware and firmware both via LimeSuiteGUI or via LimeUtil command tool - nothing works.

So I got two questions:

  1. Are the HF-modified boards tested at all after doing this modiciation? Two out of three of such boards which I have received were faulty and it should be detected when trying to run pretty much any test since they throw error in every single app…
  2. How should I proceed now in order to finally get second undamaged, HF-modified LimeSDR board?

If you have any ideas what can I try I would be happy to try them, but as the very first board runs perfectly fine I am really quite sure I do everthing right and it is not a matter of host machine or OS configuration…

2

@ccsh,

Please try your Lime in the VHF band (like 162.55 MHz for weather band) or a known active VHF frequency. I too have seen some HF weirdness but it plays fine in VHF. Try it and report back with your findings.

73 de Marty, de KN0CK

3

I am unable to use that board on any band since it throws error during initialization, as described above.

4

@ccsh,

It does look like your HF modified board has a hard error - - I would consult with @andrewback to see what recourse you have…Third time is the charm…?

73 de Marty, KN0CK

5

From my basic understanding of the “HF Modification” there was the removal of a component in the RX_W RF input stage of the board, therefore should have no impact on the “Logic” part of the board.

I’m not real familiar with Linux, is it possible the first board worked fine and it is some sort of permissions issue with any subsequent board not matching to original serial number that is causing the problem?

6

Hi @ccsh,

Perform automatic board update, please. Then post the result.

7

Hi @Zack. As you wish, I have repeated update test on a different host machine. Here are the results:

As you can see, it does not work neither on “master” nor “RetructureLimeSuite” branch :confused:

You are right and it should not have an impact if everything has been done properly. But every modification may be risky in case of such complex and packed board. It was just few weeks ago when experienced company has fried our USRP B200 mini during replacing of literally several capacitors :wink: That is why I have asked whether any tests were performed after doing HF mod.

I have thought so too, but ruled it out, since it happens even when I connect that particular replaced board as a first one on a fresh linux installation.

8

Also I should note that when repeating update procedure many times in a row, sometimes (very rarely) it actually works fine, and I am able to probe the board sucessfully as long as I don’t pull out the USB plug. Now, this is just a blind guess, but it sound a little bit similar to the problem of too short pause after FPGA reset, fixed for LimeSDR mini recently by @IgnasJ in this commit. I am not sure if this fix has been applied only for LimeSDR mini or “big” LimeSDR as well. If the latter is not the case, is there a chance to create a test branch with such fix? I could check whether it helps or not.

9

That fix is only for LimeSDR-Mini

10

Okay, but I guess there are also similar pauses during “big” LimeSDR programming procedure, right? I would really use a test branch with them being increased, because this whole problem feels like unrealiable programming (as I wrote, sometimes programming can be completed successfully and then these boards work correctly as long as I don’t pull out USB plug). This is the only idea I’m having before asking for another replacement…

Is there a chance to provide such test branch? (I would do it myself, just don’t know where to look, as these source files named “ConnectionFT601” don’t tell me much :confused: )

11

I did some further testing today and found very interesting relationship. At first, let’s define “stable” and “unstable” state of the device:

def. “stable state” = state at which device may be probed (with “SoapySDRUtil --probe” command) two times in a row without throwing a single error (make sure that USB plug is not plugged out between these calls).

def. “unstable state” = state at which device is not in a stable state (i.e. it thowed at least one error during procedure mentioned above).

As I wrote before, it looks like if the device is in stable state, it stays here as long as I don’t pull out the USB plug. But if I will pull it out, it may recover and go into stable state again, or may fall into unstable state. I wanted to check if there is some relationship between the time of keeping the device unpowered and chances that it will fall into unstable state. So I did some testing according to following algorithm:

  1. Determine maximum number of runs Nruns_max and time Toff of powering off the device.
  2. Initialize Nunstable and Nruns counters with zeros.
  3. Put the device into “stable state” by updating it with “LimeUtil --update” command in a loop (usually 1-3 iterations are enough).
  4. Unplug the USB plug.
  5. Wait Toff seconds.
  6. Plug in the USB plug.
  7. Increase Nruns.
  8. Run “SoapySDRUtil --probe” command twice and look for errors (i.e. check if device is in a stable or unstable state). If at least one error was found, increase the value of Nunstable counter.
  9. If Nruns==Nruns_max, go to step 10. Otherwise, if errors were found in step 8, go to step 3. If no errors were found in step 8, go to step 4.
  10. Estimate the probability Punstable that the device will fall into unstable state as (Nunstable/Nruns)*100% and end the test.

Here are some results:
Toff=5 seconds: Punstable=(4/20)*100%=20%
Toff=10 seconds: Punstable=(12/20)*100%=60%
Toff=20 seconds: Punstable=(19/20)*100%=95%
Toff=60 seconds: Punstable=(10/10)*100%=100%

So I have found obvious relationship between time of keeping the device unpowered and probability that it will fall into unstable state. @Zack, @IgnasJ, does it ring a bell to you? If not, could you tell me where are initialization-related time constraints (such as length of a pause after FPGA reset) kept in a source code for “big” LimeSDR board? I would be happy to recompile LimeSuite with their different values, so I could check whether it helps at all or not.

P.S. I have tested it with the most recent “RestructureLimeSuite” branch, as it shows more errors than the “master” branch.

12

Hi @ccsh,

When device is in “unstable state”, do you see LimeSDR-USB board when lsusb?

13

Yeah, and I have compared the verbose output of lsusb in both stable and unstable state. There is no difference at all, in both cases it is as following:

Bus 004 Device 010: ID 1d50:6108 OpenMoko, Inc. 
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               3.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         9
  idVendor           0x1d50 OpenMoko, Inc.
  idProduct          0x6108 
  bcdDevice            0.00
  iManufacturer           1 Myriad-RF
  iProduct                2 LimeSDR-USB
  iSerial                 3 0009061C02CA2B20
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           70
    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     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst              15
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst              15
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x0f  EP 15 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x8f  EP 15 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst               0
Binary Object Store Descriptor:
  bLength                 5
  bDescriptorType        15
  wTotalLength           22
  bNumDeviceCaps          2
  USB 2.0 Extension Device Capability:
    bLength                 7
    bDescriptorType        16
    bDevCapaCouldn't open device, some information will be missing
bilityType      2
    bmAttributes   0x00000002
      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)
14

Hi @ccsh,

Why you getting this strange string in the middle of verbose output of lsusb?

15

I just forgot to run lsusb with super user privileges.

I have check it again and confirmed that there are no differences between lsusb output in stable and unstable state:

Bus 004 Device 019: ID 1d50:6108 OpenMoko, Inc. 
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               3.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         9
  idVendor           0x1d50 OpenMoko, Inc.
  idProduct          0x6108 
  bcdDevice            0.00
  iManufacturer           1 Myriad-RF
  iProduct                2 LimeSDR-USB
  iSerial                 3 0009061C02CA2B20
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           70
    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     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst              15
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst              15
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x0f  EP 15 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x8f  EP 15 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst               0
Binary Object Store Descriptor:
  bLength                 5
  bDescriptorType        15
  wTotalLength           22
  bNumDeviceCaps          2
  USB 2.0 Extension Device Capability:
    bLength                 7
    bDescriptorType        16
    bDevCapabilityType      2
    bmAttributes   0x00000002
      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)
16

I had a break for a while. Today I recompiled everything (fresh linux) and encountered similar behaviour to what you encountered. So I reverted to old sources(from last time I did something) and everything works as it used to! Try this commit:
git checkout 9c365b144dc8fcc277a77843adf7dd4d55ba6406
Maybe there is something in the code.
With now sources I managed to run my application but changing frequency caused crash. Also PAD amplifier is not responding.
@zack were there some major API changes?

17

Will try that on Tuesday, but as I am struggling with that issue over past few months and other board works perfectly fine both on old and current drivers, I don’t think that’s it. I will report results though.

18

Okay, so I have tested this commit, which is the closest commit to the one proposed by @modimo, for which I am able to download source files. Surprisingly, the issue with device probing was gone indeed for this version of LimeSuite. However, it doesn’t mean that it worked successfully, since I was unable to transmit or receive anything, and got following warnings when trying to set RF frequency of 1455 MHz:

The same was happening for any other frequency in TX or RX, both in GNURadio UHD-based application and custom SoapySDR-based application.

So, right now I got two “options”: recent LimeSuite version which is unreliable in terms of board programming and throws error even when simply probing the device, or some ancient version which doesn’t throw such errors but also doesn’t allow me to transmit or receive anything. @Zack, do you have any other ideas?

19

This warning is due to calibration cache. Try removing it and/or disabling.

20

Actually I have passed “cacheCalibrations=0” in device arguments, but it didn’t help.