This is how I do it.
I would just add that if you want the bleeding edge you can run ‘git pull origin dev’ at the base of your sdrangle directory.
Otherwise ‘git pull origin master’ keeps you updated with the latest release.
Then you just re-run the above starting with ‘cd build’.
1 Like
@Axeman - Lance,
What other dependencies would I need for 17.04 beyond the git pull? Lemme know - REAL motivated to get this going based on your threads last night on 2m…! Keep me advised - 73
de Marty, KN0CK
@martywittrock
Usually, you get an error at the cmake or make step if any library it needs is missing. Then you install the dev version of whatever it complained about using apt-get or aptitude. I like to ‘aptitude search foobar | grep dev’ using a relevant word part from the error. This will usually turn up some package without an “i” in front of it.
When I start sdrangel in a terminal it reels out a long list of messages that look like error messages that I haven’t read because it works and the window covers them up right away. I think it’s checking it’s environment.
1 Like
@Axeman - Lance,
Mine blew up - - wouldn’t start because of some dependencies, so that’s why I’m keen to make sure those are there first before I compile it, too. Compile went fine, it’s just when it started up is when it blew up this morning…
73 de Marty, KN0CK
Try this from the git page:
sudo apt-get install cmake g++ pkg-config libfftw3-dev
libqt5multimedia5-plugins qtmultimedia5-dev qttools5-dev
qttools5-dev-tools libqt5opengl5-dev qtbase5-dev libusb-1.0
librtlsdr-dev libboost-all-dev libasound2-dev pulseaudio libnanomsg-dev
libopencv-dev libsqlite3-dev
I remember doing this once and it found some things that weren’t there. You may have to delete one of them or another if it errors out. There may be a newer or different version on your system.
1 Like
Two libs were missing, can not remember now which one,
must dig a bit and try to find out later today.
73
Djani
1 Like
I get some signal messages at the beginning:
QMetaObject::connectSlotsByName: No matching signal for on_sampleSource_confirmClicked(bool)
QMetaObject::connectSlotsByName: No matching signal for on_sampleSink_confirmClicked(bool)
QMetaObject::connectSlotsByName: No matching signal for on_channel_addClicked(bool)
It seems like it would need these. These are not dependencies, they are code elements (bugs?). It works anyway. All the other messages scrolled out are about plugins.
1 Like
@Axeman - Lance,
I saw those same messages, but mine didn’t start - terminated because of some other (later) dependency…So I’m going to just format and put 17.04 on and see what improves - but thanks for passing that info along - 73,
de Marty, KN0CK
Hello Marty,
on 16.04 the “sdrangel_3.5.4-1_amd64.deb” in the releases section should install just fine with sudo dpkg -i … But you wouldn’t get the Tx latency fixes that are only on dev branch. 3.5.5 is coming soon anyway. I need to add some more doc and maybe correct something for the BladeRF.
Don’t worry about the “signal” thing. This comes from Qt. I think I looked at it but didn’t fix it in the end because this was creating another worse issue.
Best regards, Edouard.
1 Like
@F4EXB - Edouard,
OH, okay…@Axeman had mentioned that one of the builds that he was working with had a pretty great reduction in the transmit delay (1/4 second from his post: “…I got it sounding great. There is a quarter second delay, as said. I had to turn my mixer control for the mic down to 25%…”). I’m preparing to move to Ubuntu 17.04 this evening and will set up SDRAngel on that version instead of the existing 16.04 version I have now. My 16.04 is pretty fragile because I’m getting other errors when I try to do a system update prior to installation. So I think the best course of action to take is to format and move to 17.04 and then load everything on - I haven’t that much to lose on my Linux box since I use it strictly for this kind of test/checkout. It’s always a good thing to move to a newer version for me in the long run… 
But I will look for those issues that you’ve mentioned and see if I can get SDRAngel running on my Linux box this evening - please stay tuned…
73 de Marty, KN0CK
Hello,
please note that I had to remove Windows 64 support for LimeSDR since v3.5.5 so Linux is not just an option anymore at least for this version. I have tweaked some files to be able to compile and maybe by tweaking the new versions the same way I can get it working so Windows support may be returning in a next version.
Best regards, Edouard.
1 Like
@F4EXB - Edouard,
That’s a good move because even this morning on the LimeSDR Facebook page there are Windows users that still want the application to work in Windows. There are just too many Hams out there that have their LimeSDR setups around a Windows PC not to have SDRAngel working on that platform, too.
On a completely unrelated note I have my Linux box loaded with Ubuntu 17.04 now and also loaded the dependencies as well to make SDRAngel operate on that platform. Everything compiled and installed, I had transmit running last night (it was midnight by the time I was testing that) and I noticed that the transmit delay is still there - - Will that be something that you’ll be applying to Github pretty soon (version 3.5.5)? I would like to run my setup without the delay for performance. I already observed a pretty noticeable improvement in the tuning (sample rate, filtering, etc) from my Windows PC. I should have looked at the version when I had that running to see what version I pulled from Github last night and compiled. I’ll check that when I get home from work today. But let us all know if 3.5.5 will be coming soon. Thus far the performance of SDRAngel on a Linux box is pretty good - seems better than Windows in some respects, but there are some tuning parameters I’m still waiting for to change when I tune them, but the wait time seems less running Ubuntu17.04 than Windows 10.
Keep us all advised on the latest SDRAngel update, Edouard - it’s just getting better and better with each release…!
73 de Marty, KN0CK
@Axeman - Lance,
As it turned out those dependencies worked perfect on my install without any further changes or additions. Just loaded LimeSuite from source, compiled, installed the dependencies, installed and compiled SDRAngel and everything worked right out of the chute…! Thanks for passing along those dependencies, Lance…!
73 de Marty, KN0CK
@martywittrock,
You’re welcome, Marty. On some of the better git pages you’ll find a list of libraries they need to compile. Having a ‘.deb’ package would pull in all the dependencies automatically.
Now if I can only get gnuradio-companion working again. It seems to not like Python, which it depends on. Something about an illegal pointer call by free().
1 Like
@Axeman - Lance,
When I did my pull of SDRAngel last night it didn’t seem to have the transmit delay issue fixed…Does yours still have the delay (I don’t think it does from what I read a couple of days ago) but for some reason the pull and compile I did still has it. Let me know if I’m doing something wrong with that…
73 de Marty, KN0CK
Try the ‘git pull origin dev’ in …/sdrangel and do the ‘cd build’ forward process again.
I don’t remember exactly when I pushed the merge on master but sure it is on master since 00:00 CEST today (10th August).
The 0.25s delay floor (only on the sample FIFO but that’s the major bottleneck) is for baseband sample rates down to 192 kS/s with lower rates it will grow as 48/SR with SR as the baseband sample rate in kS/s. Still better than the 6s for the usable rates (>= 48 kS/s).
On another note I have succeeded in building the minimal LimeSuite for Windows used internally based on 17.06.0. I have still to try if it works. I’d rather have no support than a breaking one. Also 17.06.0 seems to be a must judging by the Linux side.
Best regards, Edouard.
2 Likes
I can’t get more than a 0.5s delay now. I was trying.
There are still a lot of random freezes and segfaults. They seem to be related to buffer fills and clears. Like when you start a transmit and it is creating buffers and pipes and you change a gain or sample rate or antenna or frequency, etc., it gets lost. Maybe a buffer overflow or something dumping on the stack. It could be a kernel problem on my end, IDK.
@F4EXB - Edouard,
Well, something happened to my Ubuntu 17.04 installation to make it very unstable so I fell back to Ubuntu 16.04 64-bit and performed all the necessary steps to setup SDRAngel and the dependencies. SDRAngel 3.5.5 starts, but it cannot ‘see’ my LimeSDR even though I have LimeSuite installed per your directions…Still nothing - SDRAngel cannot see the LimeSDR at all. Then I thought I would need SoapySDR so I installed SoapySDRUtil…still nothing…SDRAngel cannot see my LimeSDR.
Not sure what’s happening here…24 hours ago I was able to control my LimeSDR with SDRAngel and everything looked fine (albeit in the older version 3.5.4.7)…Today, 17.04 becomes brittle, falling back to 16.04 for a complete install gets SDRAngel running - yet no LimeSDR support - it cannot be selected and I know my LimeSDR is in fine shape because when I plug it into my Windows PC it starts right up with SDRConsole and receives fine.
What suggestions can you provide me where to start looking? I’m punked that my setup has been formatted twice and now it’s REALLY broken…
73 de Marty, KN0CK
Hello Marty,
I’m wondering what could cause Ubuntu to become unstable. Anyway with 16.04 the provided .deb package should be perfectly usable since it is built with Ubuntu 16.04 precisely.
So please install SDRangel with the provided .deb package: https://github.com/f4exb/sdrangel/releases/tag/v3.5.5
- sudo dpkg -i sdrangel_3.5.5-1_amd64.deb
- sudo apt-get -f install (if still missing dependencies)
start with: /opt/sdrangel/bin/sdrangel
Best regards, Edouard.