@brendanthebig I think this is more because of changes made in the LimeSDR plugins. Now the center frequency is the actual center frequency taking NCO into accoun with the NCO dial showing the actual frequency shift. Before the big dial was the LO frequency and the NCO dial the actual center frequency. I think this was a bit confusing moreover it messed up the center frequency if you use the preset with a device not having a NCO (anything else than a Lime). You can still see the actual LO frequency in the center frequency tooltip message. If you use a preset saved from an earlier version it will not interpret the center frequency the way it does now. So indeed loading and correcting then saving with the new version should solve the issue for future preset loads.
@martywittrock I am also waiting for things to mature a bit on the LimeSuite side. I was still able to get a clean Tx modulation from a Lime-USB attached to my Windows7 machine. The Lime-mini Tx is messing up in all cases.
I’ll try the latest on the Windows machine this evening - what’s running on my two Linux boxes on Ubuntu on an older version is still doing fine…So I’ll wait for the latest for Ubuntu.
I just tried the latest version of LimeSuite (commit 67dcef1) and it appears to fix Tx problems for both Lime-USB with new gateware 2.16 and Lime-Mini with current gateware 1.4.
I have been testing my PLUTO with SDRAngel (W7Pro, run as administrator, SDRAngel version 3.14.7, I7-6700). It is functional on both receive and transmit. However, the power output measures -18 dBm instead of the expected +7 dBm (2304 MHz, SSB modulator, either tone, CW, or peak SSB).
NFM is also -18 dBm out
AM is -23 dBm out
WFM is -25 dBm out
Using IIO Oscilloscope to set the transmitter to a single tone at 2304 MHz, the power output is right at +7 dBm.
Has anyone else observed this issue? Are there commands/workarounds to get the power up to +7 dBm in the short term?
I have fabricated and partially tested a board to sample the Tx RF, extend the pulse to key a GVA-82 amp and solid state TR switch to work at 2,3, and 5 GHz.
Thanks
73, Mike, W3IP
You are aware that there is a transmit gain control in SDRAngel that you can adjust to get the max or minimum power? Please look for the slider control for transmit gain and it’ll provide a smooth adjustment range. Otherwise you may want to get with Edouard (F4EXB) on that…
Thanks for the response. I see a “knob”, on the “T1” Sampling device tab that controls the transmit output level from -18 dBm down to the noise floor. If you hover over the knob, it says “Reverse gain (attenuation) setting (dB)”. I also see the FIR gain (drop down menu choices are 0 and -6 dB). I am not spotting a slider that might control power levels. The only slider on the T1 tab I see is the LO adjust, the sliders on the SSB modulator control bandwidth and file playback position. Am I missing one?
I have continued to try to figure out why I see output power on two separate PLUTOs that are 24 dB below what it should be. I see on my spectrum analyzer that the transmitter attenuator function (0 to 89.75 dB) works correctly. By setting the TX interpolation to 1, the FIR and half band filters are bypassed. Looking at the block diagram of the AD9363, the I/Q input level 4 bits low or the antenna switch in the “B” position are the most likely suspects. I have been looking at the code, but am not expert enough to spot anything amiss. Anyone have any other ideas to test?
Marty y compañeros, queria que vierais una demo del uso del openCL usando la capacidad de calculo de las gpu (tarjetas graficas)
y tener en cuenta esta mejora no solo para el procesado del waterfall, si no tb para la latencia del tx.
Observar la velocidad de proceso en tiempo real.
Y todo esto usando usb2 o usb3 pero es de suponer que si usaramos pcie la velocidad seria mayor y bajariamos la latencia.
The LimeSDR id best suited for USB 3.0 operation - it’s not advised to use USB 2.0 when running the LimeSDR with other applications. Certainly PCIe would be faster since you’re at the edge of the PC’s hardware and not dependent on an I/O with an abstraction layer (like USB) to add latency.
Latency will always be an issue with Software Defined Radios of any kind and the interface they’re connected to. No matter which SDR you end up with, each will have their own ‘bottlenecks’ that are inherent to their own design and to the interface they use to stream their data. I’ve used the LimeSDR on a number of different platforms (PC, LattePanda, UDOO card, Pine64, etc) and with Windows and Ubuntu OSs. One thing is clear - you have to have a computer that runs at least at 2.2GHz and has USB 3.0 resources for the LimeSDR to be effective. As I mentioned, it’s not recommended that you run the Lime on USB 2.0 - it’s performance will be severely limited with the app it’s coupled to.
I have been testing my PLUTO transmitter with SDRAngel version 4.0.0 and 4.0.3 and find the power output is consistently 24 db (4 bits) low (i.e. -18 dBm out instead of + 6 dBm out). Looking through the source code, I see the line of code that appears to left justify the 12 bit symbol in the 16 bit signed integer has been commented out (plutosdroutputthread.cpp line 97). Would it be possible to enable this code to achieve full transmitter output?
Mike,
The PlutoSDR is a bit different. It does not seem to have a control to change digital (baseband) gain, unlike other SDR devices. I was working recently on adding Pluto support to qradiolink via a fork of SoapyPlutoSDR and I discovered that I needed 50 times more digital gain than the USRP or LimeSDR before ADC clipping. Unfortunately, the chages I made to the plutosdr branch seem to have broken my LimeSDR mini transmit. I can’t tell what is the cause, because I have a pre-production board and I get some errors when I try to set sample rate to 1 Msps (telling me I have requested 10 Msps).
Adrian
The PLUTO AD9363 transmitter evidently uses 12 bit signed integers left justified in a 16 bit word to feed its DAC and IQ modulator. The RF signal then passes through a 0 to 89.75 dB attenuator in 1/4 db steps to digitally control the output signal level. Edouard has now found and fixed the low output level problem, so the latest version of SDRAngel (4.0.4) puts out full power as expected. His release notes detail the changes he had to make.
Regards
Mike
The good news is that adding PlutoSDR support did not in fact break the LimeSDR and the errors were caused by the USB cable. I think there should be a big warning label on the Lime mini about using USB 2.0 or too long cables.
