SDRAngel can cause LimeSDR to appear 'dead' like a bad setting...

[martywittrock]

After running the LimeSDR on the VHF band (local weather at 162.475 MHz) I used by preset to return to the HF band and observed that the band appeared dead when earlier, that preset worked perfect. I stopped the receive stream by clicking on the green button to stop the stream and then clicked on the resulting arrow to restart the receiver - - worked. It's as if - sometimes - you have to double-hit the applied preset to make everything start properly but for a few moments it can look like your LimeSDR is dead. Just reporting this incident since I am planning to set up my LimeSDR on a new platform tomorrow and just getting my settings all lined-up so the 'port' to that new platform will be error free. Again, double-hitting the stream seems to work, but I haven't tested this extensively. 73 de Marty, KN0CK

[f4exb]

The way the preset populates the data has to be redesigned anyway. The configuration is passed via the GUI which is not a very good design and certainly a very bad one in view of future headless operations. To this occasion I can check the scenario you describe and figure out if this can be improved

[mntnmn]

I have noticed LimeSDR can do this 'lockup' in other applications as well. Even LimeSuiteGUI. A wild guess by me would put the problem in the MCU's VCO tuning routine.
With SDRAngel, I like to scan the bands 10MHZ at a time by setting the sample rate and bandwidth to 20Mhz and using the arrow key on the tens digit. Sometimes the display suddenly shows only wideband noise and I can't go back to a signal. Resetting the LimeSDR may bring it back or just a large frequency change and back will work sometimes.
In LimeSuiteGUI, I may be making small changes to tune something and it will start complaining that the VCO can't be tuned. If I try the same setting from the beginning it is OK. Sometimes all I can do is power down reset and start over. Dropping in a setting with an INI file will always work while trying to get to the same setting in the GUI will not always work.
Lance,AK6MN

[f4exb]

I have tried various scenarios trying to run Rx and Tx at the same time and this definitely doesn't work and sometimes locks up the LimeSDR. I don't see a reason for this other than a problem with LimeSuite or the way it is used.

[f4exb]

Just tried LimeSuite 17.09 and it appears to be more stable. For example this scenario works: 1: start Rx in the Rx tab, 2: add a sink tab and select the (same) LimeSDR, 3: start Tx. Previously the last step would fail on Tx stream set up.

[f4exb]

Please try v3.7.2 that is compiled with LimeSuite 17.09

[martywittrock]

Hi Edouard,

I have tried the latest version of SDRAngel (v3.7.2 for Win64) and it seems to be A LOT more solid on receive than prior versions. It now starts and stops pretty well without any issues - so that appears to be fixed but I'll keep my eyes on it, too.

However, when I load a sink device for transmit and I switch off the receive (source) and switch on the transmit (sink) stream, the transmit will work fine for as long as I choose to operate it, but when I switch off the transmit device and then try to switch on the receive, the receive does not start up. It seems to hang and I have to restart the application completely (leave SDRAngel and then restart SDRAngel and then reload all my presets, etc). Not sure if this matters or not, but this is all being worked on the HF bands (generally testing it on 40m).

Can you check this? This is on the Win64 build and it's been working on receive wonderfully on my LattePanda board with the 7" touch screen and the microPC that I intend to embed to make the wideband transceiver using the LimeSDR. There has been A LOT of interest in my work with SDRAngel running on the LattePanda board on Win10 and many hams appear to be putting this configuration together for their own transceivers - it's a great combination for a VERY portable rig.

Keep us advised on the issues, Edouard - 73

Marty, KN0CK

[f4exb]

This last issue is tracked with a new issue opened by the reporter: #67 This one can be closed