Lime report

[PA3GUO]

My spectrum looks a bit odd, so I checked my lime report.

It shows these errors. Has anyone seen this before?

Henk PA3GUO

[G8GKQ]

Hi Henk

Those errors are normally nothing to worry about on their own. There is a fault in the version of LimeQuickTest that is used to produce the report that causes frequent spurious test failures.

A newer, more reliable, test program is now available, and I hope to incorporate it in a future Portsdown build.

Dave

[PA3GUO]

Hi Dave

Thank you for the quick response.
Relieved that the most expensive component may still be doing OK.

Henk

[vk3vcl]

Greetings all
I came here this morning specifically looking for the same answers as the original poster.
I am relieved to see it is a known issue and not a hardware fault.

Some more symptoms for anyone else stumbling across this issue, as well as a minor anomaly:
First, the test results here on first start up often show all areas tested as Passed.
It is only on subsequent testing that the failures show and they are not always the same:

The last four categories, shown below, often show different results, for example, a fail or pass...then all pass or most fail. I am yet to see the Custom FPGA Test failure which I can only assume is an extension of the FPGA EEPROM Test.

TX 2 LNA_W Test
TX 1 LNA_H Test
RF Loopback Test
Board Tests

The anomaly is in PA operation after initial boot.
You start the system with the intention of transmitting. As no settings have changed (usually) you then line up your ducks and press TX.
All appears to function fine up until it is time for the PA line to key. It wont.
I find I must go back, carry out a lime test and then all works as intended.

Is this a feature or a bug? I must admit, I have looked at the documentation but am yet to find the answer, I admit it was a thin skim.

Note: I am not using the Portsdown 4 band decode PTT board as I only use one band, rather just a single LH1540AT solid state relay with some finergeling upstream to key the PA.

[G8GKQ]

Hi

You should not have to do a Lime Report to enable transmit. In fact it suggests a problem if you do have to. Probably power-related with USB power to the Lime.

Is the LED on the LimeSDR flashing red/green when you first switch on and try to transmit?

Please try with the Lime directly plugged into the RPi or with a different USB lead.

The Lime Report is only valid when the LimeSDR is cold (at first switch-on), and without anything connected to the SMAs. As such, it is pretty useless in the Portsdown. All my LimeSDRs fail occasionally.

Dave

[vk3vcl]

Thanks for the reply Dave

Some updates for you and anyone interested.

I have now connected the Lime via an old style, 2 x USB A - Y cable to a USB A Female. These were common some years back for devices requiring a little extra juice. The Primary A plug goes into the lower Pi USB 3 Port. The Secondary A Male goes to a separate 5V supply. The cable is about 20cm long.

The 920C Camera is plugged into the upper USB 3 port.

The Waveshare port is connected to the lower USB 2 port and the Mini Touner to the Upper. The Mini Touner is powered by a second Y cable as per the one above.

What has this done, well, It solved most of the audio issues. No more stuttering audio.
Second, I now get no errors on the Lime at all. No matter how long it operates.

I improved the earthing to all components so Its a bonded earth system and overall I have significantly improved performance on almost all modes.

Curious to see if others have similar results.

several hours later....

I saw no failures on the lime tests because i was still in DVB-S Mode. After I realised this I changed to DVB-S2 and tested, there the failures reports were present again. I shut down, rebooted and tried again in DVB-S, no failures.

Was this reporting protocol in the lime a result of the mode or possibly the change from one mode to the other.

Wayne