No success on lighter hardware like RPi3 on Raspbian. I couldn’t try with openSUSE ARM64 because OpenGL does not install successfully by default. openSUSE performs largely better than Raspbian in a server configuration.
BTW, he’s the OM running at the blazing speed of 30 MS/s
Also I am running a CW beacon in WFM 125 kHz wide (50 kHz deviation) at 175 kS/s in the baseband and I can tell you the dots and dashes are perfect. Software upsampling by 16 makes a 2.8 MS/s rate at the input to the Lime and ~8.4 MB/s on the USB link as reported by the Lime. The hardware interpolator upsamples by 8 so this makes 22.4 MS/s at the DAC with the 5 MHz (lowest) bandwidth hardware filter and 200 kHz hardware FIR filter. The output is very clean.
Although the maths are simple adding the actual DAC (ADC on Rx side) sample rate to the GUI may better catch attention. This will probably be part of the next v3.5.1
Getting SDRangel running under Ubuntu 17.04 was pretty easy for me. I simply did a clone of the github repository, ignored the README.md, did a ‘mkdir build; cd build; cmake …’ I noticed I was missing a couple dependencies. I then read the README.md and googled where to find and installed the dependencies I was missing. I am running the latest LimeSuite from github. Honestly it was pretty straight forward.
I haven’t read the rest of this thread, but if there is an issue with running at 30Msps I’m surprised. I do find I have to run at a hardware and software decimation rate of 4:4 to get any decent performance and not to drop packets. Since I have gqrx running at 60Msps, I was expecting SDRangel to do the same.
In case anyone is curious, I am running Ubuntu 17.04 on a 6 core (12 logical) i7 with 32GB RAM. I did run into problems with my built-in USB 3 ports, but installing a recommended pcie card solved that problem. I don’t remember the brand or model of the card - it’s in another thread that I initiated.
I should say I really like some of the ideas that are in SDRangle. Since I run Ubuntu, I typically only use gqrx or pihpsdr when using my LimeSDR boards. Having an app that is as flexible as SDRangle is really nice. I am already contemplating adding support for decoding AX.25, PSK, WSPR and adding support for DX spotting, scanning, and bookmarking. The plug-in support is really exceptional.
I have chatted with Edouard over email about adding a different UI presentation. I’d like to see something more akin to a light pihpsdr style interface that can fit on a RaspberryPi3, Odroid XU4, or even a future zynq-ultrascale board (which has 64bit and graphics support). I’d like the interface to fit on various sized touch displays (5", 7", 10", etc.). This app would be a separate app from SDRangle, but would be built on the same code base, just with a different QT front-end.
Feature request!
A pipe from receive at one frequency to transmit at another (within limits). I was looking to use an audio device as a source file for modulation. It wants a raw audio extension.
Is there a way to output the audio to fldigi or some other such app? For fsk or psk?
This is still one of the best behaved interfaces to the LimeSDR. I am working to get all of the other ones running but this one worked from the start with minimum effort. I think I will study this code to see why it works so well.
Djani, it may not be freezing - I got no apparent response with initial settings that the LimeSDR receiver used. Make sure you have the hardware and software decimation set appropriately. For “normal” use I have mine set to 4: 4, or 2:4.
Most of the libraries you are missing are for devices. You don’t need them unless you have a device you want to use. The libcm256cc and libnanomsg I either googled for the package to install and did an ‘sudo apt install …’, or for the github repo for them and built and install them manually.
I get freezing of the stream when changing frequency or bandwidth sometimes, randomly. I have to exit the program and restart. Sometimes I have to unplug the Lime and replug it in.
Another thing I just noticed is if I set the frequency to 30.000 MHz I get a washed out spectrum but if I set it to 30.600 MHz I see all of the signals. I can then NCO into this and demod those signals. This is a LimeSDR problem and not sdrangle. I see this in LimeSuiteGUI too.
I find the LimeSDR to be a very buggy bit of kit. I believe many of the bugs will be worked out though.
@martywittrock
Sure Marty
BTW my impression from today is that with some other TRX backup and antenna switching
QRP CW QSO may be possible even now… today my CW went over SSB module and some
spurious (two - one carrier bellow and one mirror CW above main freq) are present within 8 MHz
near bandwith on 432 MHz. Monitored on SDRPlay RSP1 & CubicSDR.
My Agillent test set is on mainland, so can not measure with accuracy but both approx 30-40 dB bellow
main signal.
73
Djani
Back in mid to late May CW and SSB was functioning, but the results I was getting was that the CW was not correct (dots and dashes were not following conventional Morse Code) and that the SSB audio in USB and LSB was very distorted and almost seemed robtic no matter how I adjusted the gain or the sampling rate. So I’m interested in knowing now - from independent sources - if there’s been any improvement since that time (back in May). Post video results of CW and U/LSB audio if possible.
FYI
The same is on my Win 10 notebook.
But, today CW on ubuntnu17.04 was ok, even on higher speed.
Any adjustment for example PA gain and proper CW is gone…
Pls allow me couple of days for video… limited on equipment here
73
Djani
concerning the “pipe” feature it is there aolmost… On the Rx side you have the UDPSource plugin (that is a source for outside SDRangel) that can output I/Q samples from its channel via UDP to a remote (or local via loopback device) application. Now if we had the Tx counterpart UDPsink you could also pipe back into SDRangel. I once thought of internal piping and having some sort of switchboard GUI but the UDP thing is certainly easier to implement and more versatile.
concerning FlDigi it is missing the option to take samples from the standard input instead of only the audio device (I think) otherwise by using the same means of UDPsource plugin it would be easy to netcat from UDP and pipe in FlDigi. I have been using a similar setup for piping samples (FM demodulated which is an option of UDPSource) into multimon and get APRS decoding working. See my comments on this issue: https://github.com/f4exb/sdrangel/issues/25
So to summarize I think I will add UDPSink to the list of next features (via enhancement issue).
Quality and level of sound is poor, but hope you can get
some impression any way
Setup is the same except the signal is taken with swr directional coupler
73
Djani
