BATC Forum

I have just created a new version of the Langstone transceiver software that works with both the Lime SDR Mini and the Adalm Pluto.
I have created a new Github repository at https://github.com/g4eml/Langstone-V2 for this version of the software. I would recommend building a new SD card if you decide to give it a try. There are several 'under the hood' changes to the way the software works so I am sure there will be bugs to be found.

There are in fact two separate programs, one for the Lime and one for the Pluto. Both versions are created when you build the SD card.
At the end of the SD card building process you will now be asked if you want to use the Lime, the Pluto or to be presented with a touchscreen choice at boot time.
The basic features of the Langstone program are the same as before, so if you do not have a Lime SDR Mini there is no real need to change at the moment.

The Lime version has coverage from 30 MHz to 3.8 GHz. So you will gain the 50MHz band over the Pluto but you will lose coverage above 3.8 GHz.

I have not yet done a thorough test of the Lime's performance but it appears to be very similar to the Pluto. Its USB connection also seems to be more reliable than the Pluto's, so far it has never dropped off line which is annoyingly quite common with the Pluto.

There are a couple of things that I have spotted.

The Lime will produce a very slight signal glitch occasionally while tuning. The glitch appears to happen whenever the Lime LO frequency is changed and this happens every 100KHz with the current software. The Lime frequency is being controlled via the GNU Radio module and it is this that is producing the glitch. I had a similar problem with the Pluto that was fixed by programming the Pluto's frequency directly, bypassing GNU Radio. However at the moment it doesn't appear to be possible to do the same with the Lime.

If you have a freely rotating tuning knob and you spin it quickly it may take some time for the Lime to catch up with the displayed frequency. This also appears to be due to the time it takes for the GNU Radio module to change the Lime frequency. Frequency change requests can queue up waiting to be processed.

I have also just taken delivery of a Lime RFE amplifier module and I am planning to add support for this in a future Langstone release.

Colin G4EML

Thanks Colin: good news!

i2NDT Claudio

Great news Colin will this work along side the PD4 software in the same way it does with the pluto only version ?

John G7jtt

Hi John

There are no conflicts between the new Langstone software and the Portsdown 4 software, however, the Portsdown software needs some modifications to work seamlessly with the new version. So it is currently not possible to switch between the 2 using touch commands.

I'm working on it!

Dave, G8GKQ

Thanks Dave and Colin these projects just keep getting more and more useful.

73 John

Hello colleagues! Once again, I want to thank Dave and Colin for developing it project!
I tested the project with Lime-mini. Everything works well. With the help of the HF converter for the RTL-SDR key, I even tried to receive HF radio. It was an interesting experiment.

hi Colin,
how did you manage the delay introduced by the LimeSDR due to it's calibration process?

i2NDT Claudio

Hi Claudio,

I never came across the problem when running under GNU Radio. According to the Lime data, it only re-calibrates when moving frequency by more than 100MHz, and even then it is very fast.

I have no idea why it seems to take so long when used for DATV.

Colin.

Most of the delay before Lime calibration in DATV transmission is setting up the stream for the Lime. I'm sure that it could be reduced with a major re-write, but it does work as it is, and there are many other projects......

Dave

thanks very much Colin and Dave for your answers!
I will "investigate" this further and let you know my findings and conclusions.
as a matter of fact I can live with the delay while doing DATV. still have to check Langstone and SSB.

i2NDT Claudio