LimeSDR Mini 2.0 RX only works after changing bandwidth

sazrocks · 18 January 2024 08:16

Hello,
SDR noob here. When trying to use my LimeSDR mini 2.0 in SDR++ or URH on Linux, when I initially start the stream I don’t get any data. However, if I then change the bandwidth to some different value (say 20MHz → 20.1MHz), then the radio starts sending data just fine and I can use it normally from this point. This is mainly only an annoyance, except for in URH it doesn’t let me change the bandwidth after starting recording, so I’m currently unable to use that functionality.

I thought it might be an issue with the firmware on the LimeSDR but I reloaded the firmware with LimeUtil --update and there was no change.

Any suggestions on how to fix this?

andrewback · 20 January 2024 14:29

What version of Lime Suite are you using? This is almost certainly nothing to do with the hardware or firmware, and rather instead a software issue. If you plug the board into your computer directly and then while it is still cold and with nothing connected to the RF ports, run:

LimeQuickTest

This will test the hardware and also report the Lime Suite version.

sazrocks · 20 January 2024 23:12

23.10.0, I should probably have put that in the OP, sorry.

Here’s the output:

[ TESTING STARTED ]
->Start time: Sat Jan 20 16:11:30 2024
->LimeSuite version: 23.10.0-23.10.0

->Device: LimeSDR Mini, media=USB 3.0, module=FT601, addr=24607:1027, serial=1DA16E26AA5E94, HW=7, GW=2.2
  Serial Number: 1DA16E26AA5E94
 Chip temperature: 27 C

[ Clock Network Test ]
->REF clock test
  Test results: 41897; 44827; 47649 - PASSED
->VCTCXO test
  Results : 6711003 (min); 6711037 (max) - PASSED
->Clock Network Test PASSED

[ FPGA EEPROM Test ]
->Read EEPROM
FPGA EEPROM not supported in v2
->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 ]
->Configure LMS
->Run Tests (TX_2 -> LNA_W):
  CH0 (SXR=1000.0MHz, SXT=1005.0MHz): Result:(-26.7 dBFS, 5.00 MHz) - PASSED
->Run Tests (TX_1 -> LNA_H):
  CH0 (SXR=2100.0MHz, SXT=2105.0MHz): Result:(-22.4 dBFS, 5.00 MHz) - PASSED
->RF Loopback Test PASSED

=> Board tests PASSED <=

Elapsed time: 1.58 seconds

sazrocks · 21 January 2024 02:13

Another issue I’m having (I think/hope it is separate) is that the fan doesn’t turn on after 55C. I have a little noctua 5v fan connected to the fan header on the board and it doesn’t turn on at all even at 60C. I checked the polarity, and even tested with the multimeter; the pins aren’t getting any voltage at all. How can I fix this?

sazrocks · 21 January 2024 02:31

The Device Info window in LimeSuiteGUI says I have firmware version 6:

which appears to be over 2 years out of date and the latest is version 10:

github.com

myriadrf/LimeSDR-Mini-v2_GW/blob/main/LimeSDR-Mini_lms7_trx/mico32_sw/lms7_trx/main.c#L40

      
        
            //get info
            //#define FW_VER				1 //Initial version
            //#define FW_VER				2 //FLASH programming added
            //#define FW_VER				3 //Temperature and Si5351C control added
            //#define FW_VER				4 //LM75 configured to control fan; I2C speed increased up to 400kHz; ADF/DAC control implementation.
            //#define FW_VER				5 //EEPROM and FLASH R/W functionality added
            //#define FW_VER				6 // DAC value read from EEPROM memory
            //#define FW_VER				7 // DAC value read from FLASH memory
            //#define FW_VER				8 // Added FLASH write command protect when write count is 0
            //#define FW_VER				9 // Temporary fix for LM75 configuration
            #define FW_VER			   10 // Fix for LM75 temperature reading with 0.5 precision
            
            

            
#define SPI_LMS7002_SELECT 0x01
            #define SPI_FPGA_SELECT 0x02
            
            
#define DAC_VAL_ADDR  			0x0010		// Address in EEPROM memory where TCXO DAC value is stored
            #define DAC_VAL_ADDR_IN_FLASH  	0x00FF0000	// Address in FLASH memory where TCXO DAC value is stored
            #define DAC_DEFF_VAL			566			// Default TCXO DAC value loaded when EEPROM is empty
            
            
#define FLASH_USRSEC_START_ADDR	0x00400000  // Start address for user space in FLASH memory

Should I follow the instructions in the gateware repo to manually update? Seems weird that LimeUtil --update would install firmware that is 2 years out of date…

andrewback · 21 January 2024 11:04

Tagging @ricardas for comment.

sazrocks · 22 January 2024 18:46

Ok this is actually much more than an annoyance; there are a number of utilities that I’m trying to use that don’t support changing the bandwidth filter after recording has started, so the LimeSDR is unusable for me for those use cases. Is this a hardware issue with my specific unit? If so I would need to get an RMA started sooner rather than later because I need to have the unit fully functioning within the next 2 weeks.

sazrocks · 22 January 2024 18:52

Is this commit message relevant?

github.com/myriadrf/LimeSuite

Fix singleRX example to work correctly with LimeSDR Mini V2

committed 01:54PM - 30 Dec 23 UTC

sergeyvfx

+3 -0

The issue this commit fixes is that running singleRX example does not show any s…amples streaming, and logs shows: RX data rate: 0 MB/s. The fix follows the initialization order in basicRX.cpp where the TX channel is enabled alongside with the RX channel right after the LMS_Init(). With this fix running singleRX example shows samples streamed: RX data rate: 32.1454 MB/s. This is a bit counter-intuitive API from developers perspective (as in, intuitively question is why TX channel is needed for RX-only application). So it does feel like that perhaps the fix needs to be done somewhere deeper in the driver or in gateware to increase clarity of API. However, that'd be a deeper change, if it happens. In any case, until such possible change the proposal is to fix the issue in the same way as it is done in the other example. The motivation to get the example fixed is because this is something that new LimeSDR users run into as some of their first steps, so having examples properly working solves initial confusion and possible frustration.

It seems that in order for RX to work, then TX also needs to be active? The majority of software that I’m going to be using this thing with doesn’t support TX, only RX. Does that mean that I’m not going to be able to use the LimeSDR Mini V2 with any RX only software? That’s a pretty big limitation that wasn’t obvious to me before I bought the unit.

sazrocks · 22 January 2024 20:17

Ok so it seems that might be the cause of the issue. Basically none of the software out there is expecting to have to turn on the TX portion of the LimeSDR in order for RX to work (and indeed it seems this was not the case on previous LimeSDR products), which causes issues. To test this, I modified SatDump (one of the programs experiencing issues mentioned in the OP) to turn on the TX part of the LimeSDR when starting RX, and it worked, I now no longer have to change the bandwidth after starting the stream to get RX working.

It does seem really really odd to me that this is something that end user software would need to handle as a specific case for the LimeSDR mini V2. Shouldn’t this be handled in LimeSuite or even the firmware? At the very least this behavior should be documented somewhere prominently (sorry if it is already and I just missed it). Otherwise I guess I’ll have to run around making patches for every SDR software suite that I use…

sazrocks · 23 January 2024 02:58

@ricardas I saw your commit earlier today about turning on the mini v2 ADC and DAC regardless of RX/TX

I pulled this change and rebuilt LimeSuite.

This does fix the issue in SDRAngel; I can now enable RX without first enabling TX. However SDRAngle still only works if I make the LimeSDR a MIMO device. The RX only block doesn’t work.

Additionally, the commit doesn’t seem to fix the issues mentioned in the OP in this thread with SDR++ and URH. My own patch to URH to call the enable channel function for TX does fix the issue though. So it seems there is still more to do on the LimeSuite side of things.

sazrocks · 23 January 2024 19:45

This makes sense because SDRAngel automatically enables both the TX and RX channels when initializing the LimeSDR as a MIMO device:

github.com

f4exb/sdrangel/blob/943105d940c0081375eb2da3eddae694bfc64bf7/plugins/samplemimo/limesdrmimo/limesdrmimo.cpp#L123


      
              }
              else
              {
                  qDebug("LimeSDRMIMO::openDevice: Rx channel %d enabled", rxChannel);
                  m_rxChannelEnabled[rxChannel] = true;
              }
          }
          
          for (unsigned int txChannel = 0; txChannel < m_deviceParams->m_nbTxChannels; txChannel++)
          {
              if (LMS_EnableChannel(m_deviceParams->getDevice(), LMS_CH_TX, txChannel, true) != 0)
              {
                  qCritical("LimeSDRMIMO::openDevice: cannot enable Tx channel %d", txChannel);
                  return false;
              }
              else
              {
                  qDebug("LimeSDRMIMO::openDevice: Tx channel %d enabled", txChannel);
                  m_txChannelEnabled[txChannel] = true;
              }
          }

While the RX only source does not enable TX:

github.com

f4exb/sdrangel/blob/943105d940c0081375eb2da3eddae694bfc64bf7/plugins/samplesource/limesdrinput/limesdrinput.cpp#L332


      
              }
          }
          
          bool LimeSDRInput::acquireChannel()
          {
              suspendRxBuddies();
              suspendTxBuddies();
          
              // acquire the channel
          
              if (LMS_EnableChannel(m_deviceShared.m_deviceParams->getDevice(), LMS_CH_RX, m_deviceShared.m_channel, true) != 0)
              {
                  qCritical("LimeSDRInput::acquireChannel: cannot enable Rx channel %d", m_deviceShared.m_channel);
                  return false;
              }
              else
              {
                  qDebug("LimeSDRInput::acquireChannel: Rx channel %d enabled", m_deviceShared.m_channel);
              }
          
              // set up the stream

So I think that LimeSuite needs to go a bit further in terms of enabling the TX channels when enabling RX channels on the mini V2. I would try to help out on that front but honestly, the complexity of LimeSuite is far beyond my programming skills.

sazrocks · 5 February 2024 19:54

@andrewback @ricardas Do you know if this is going to be fixed soon?

ricardas · 5 February 2024 20:16

I’ve checked SDRAngel and GNURadio, they both work with Rx only.
Assuming there are no extra steps to reproduce this issue. I just pluged in the board and started SDRAngel, pressed “start acquisition”.

Did not look into SDR++ or URH yet.

sazrocks · 5 February 2024 20:28

Yes, but only in MIMO mode. Many other programs don’t use MIMO mode and thus don’t themselves enable the TX channel. SDR++, URH (in record mode), SatDump, etc. are a few examples of such programs.

Even in SDRAngel, if I plug in the board and add it as an RX only device, RX doesn’t work reliably. It only reliably works if I add the limesdr mini as a MIMO device.

ricardas · 5 February 2024 20:47

This is SISO works ok, not sure how do you even make it into MIMO. SDRangel does not show the option to add another source of the Mini v2 board.

Did you update your board’s firmware?

sazrocks · 7 February 2024 18:24

Interesting, SISO is definitely not working for me, while MIMO does. Here’s a video

I’m on LimeSuite 23.11.0-gd676b495 and SDRAngel 7.17.3

I haven’t updated the board’s firmware; I’m not really sure how I would actually do that. LimeUtil --update gives me the following output:

Connected to [LimeSDR Mini [USB 3.0] 1DA16E26AA5E94]
Existing gateware is same as update (2.2)

Programming update complete!

However, as reported by LimeSuiteGUI the firmware version is still 6, and it is unclear to me if this is the latest version as I mentioned a couple weeks ago:

ricardas · 7 February 2024 19:08

Download: lms7_trx_impl1.bit

To update the FPGA gateware, run: LimeUtil --fpga=“path to lms7_trx_impl1.bit”
then power cycle the board.

sazrocks · 7 February 2024 19:41

Ran that:

$ LimeUtil --fpga="/home/charles/Downloads/lms7_trx_impl1.bit" 
Connected to [LimeSDR Mini [USB 3.0] 1DA16E26AA5E94]
Reference clock 40.00 MHz
[100%] 1074355/1074355 Bytes programming: completed

Un plugged and plugged back in the LimeSDR, still the same behavior in SDRAngel, SDR++, etc.

Also, none of the firmware, gateware, etc versions seem to have been changed, here is what LimeSuiteGUI reports now:

ricardas · 7 February 2024 20:23

Ah, I see what’s happening. Looks like SDRAngel links to limesuite statically, so even though you updated limesuite on your machine, the sdrangel is not affected by that and uses the old version which was used to build it with (which didn’t had the “mini v2: fix #393 always enable adc, dac clocks” fix).

I didn’t encounter this problem, because I built sdrangel from source, so it linked with my latest limesuite.
If I install the sdrangel’s .deb package, then it has the same problem as you do.

cvalentine · 23 February 2024 17:42

Is there a work around for this? I 'm having the same issues.
I’ve spent hours trying to get my miniv2 working in URH and other tools.Maybe I missed the solution. Thanks!
cvalentine@cvalentine-MS-7D91:~/gr-limesdr/build/LimeSuite/QuickTest$ LimeQuickTest
[ TESTING STARTED ]
->Start time: Fri Feb 23 11:26:50 2024
->LimeSuite version: 23.11.0-1

->Device: LimeSDR Mini, media=USB 3.0, module=FT601, addr=24607:1027, serial=1DA15F32A3FC63, HW=7, GW=2.6
Serial Number: 1DA15F32A3FC63
Chip temperature: 43 C

[ Clock Network Test ]
->REF clock test
Test results: 13800; 15332; 16802 - PASSED
->VCTCXO test
Results : 6710964 (min); 6711004 (max) - PASSED
->Clock Network Test PASSED

[ FPGA EEPROM Test ]
->Read EEPROM
FPGA EEPROM not supported in v2
->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 ]
->Configure LMS
->Run Tests (TX_2 → LNA_W):
CH0 (SXR=1000.0MHz, SXT=1005.0MHz): Result:(-25.6 dBFS, 5.00 MHz) - PASSED
->Run Tests (TX_1 → LNA_H):
CH0 (SXR=2100.0MHz, SXT=2105.0MHz): Result:(-22.8 dBFS, 5.00 MHz) - PASSED
->RF Loopback Test PASSED

=> Board tests PASSED <=

Elapsed time: 1.29 seconds