Thanks for that info Edouard…All makes sense now.
Hello Marty,
many things… Firstly it does work for me in Win10 with the Lime even inside a Virtualbox which is new. Here I just watch the spectrum of the PMR446 band:
Of course one has to do the Zadig magic so that the USB driver is loaded for the Lime.
Secondly to fire up the second Rx you just do as I described. The Rx index appears on the top right of the LimeSDR control panel. It says “#0” for RX1 and “#1” for RX2. The antenna control apply which ever is the RX in use. Parameters that are common with the other RX will apply to both from one or the other control panel.
I also noticed that on Linux the reaction is better even against my native Win7. Nor Windows nor Linux in its standard version are real time OSes but Linux does a better job at getting closer to real time.
Now the last point. I have also in mind to allow headless operation. It has been at the bottom of the main readme in the “To do” list for ages. I’m afraid it is asking for a version 4.0 here. The plugins have a fairly good separation between the UI and the engine behind communicating with the Qt messaging system so they could be controlled by different means. I don’t know about the rest of the application it probably means a completely different build sharing parts. Another feature different but related would be the remote control of SDRangel via API this way you could control it with physical buttons. There are so many different hardware that the glue between the hardware and the API would be up to the user. This makes also possible to control frequency from another software like a satellite tracker. I think this last possibility has already been suggested.
Searching “angel without head” in Google brings links to the “Victory of Samothrace” statue that sits in the Louvre museum in Paris so I already have the name 
Note: it is also in Vegas of course: https://en.wikipedia.org/wiki/Winged_Victory_of_Samothrace#/media/File:Winged_Victory_of_Samothrace_Las_Vegas.JPG
Best regards, Edouard.
2 Likes
@F4EXB - Edouard,
I completely forgot that Zadig has to load the driver for WIndows 10, so I will work that again this evening and check it out on my Windows 10 PC - looking forward to that.
I do see a faster response to all the controls when I adjust them in Linux as opposed to what I find in Windows 10 - and as such I’ve been using my Linux box more as a result. 
I greatly appreciate the information and the history behind the ‘headless’ operation of SDRAngel and will pass that back to the Hams I know here at work. The application is working real well now and that’s one of the objectives is to build a portable LimeSDR transceiver that covers HF to SHF in the same box for field operations. If you should cruise through the code that’s capable of being exposed to Hardware controls, please keep me advised such that we can also look for a means of implementation, too. There’s a lot of interest around this right now.
Also, thanks for the REAL history on the ‘Headless Angel’ at the Louve and on the Vegas strip - I’ve been by Ceasar’s Palace a number of times of the few times I’ve been in Las Vegas for conferences, but the next time I’m there this will have even more meaning to me…! 
!!
Thanks again for all the information, Edouard - greatly appreciate it…!
73 de Marty, KN0CK
Hello Marty,
The problem with headless operation is that in fact it means rewriting another application from the ground up. SDRangel is a graphical application in essence. The aim of headless is completely different. Maybe some parts could be reused as I suggested but I can only see it as a complete new application. A cheaper solution would be to create another build that removes dependency on openGL. There would still be some adaptation of the code to accommodate both versions. This “light” version will still have a GUI but no spectrum displays at all and no channel analyzer plugin either. Thus I would expect it to run on a tighter CPU budget and it would remove the need of graphics acceleration making it suitable for running on a RPi3 without GPU driver constraints.
Best regards, Edouard.
1 Like
@F4EXB - Edouard,
Last night I tried the Win32 SDRAngel 3.5.5 along with Zadig and it worked perfect…! No delay in transmit and, oddly for Windows, appears to have the same performance as the Linux build. So I posted a video to the LimeSDR Facebook page and to the SDR - Software Defined Radio Facebook page, too (and one to the Cedar Valley Amateur Radio Club’s Facebook page, too - the club that has a lot of interest in the headless design). Thus far the Linux build had started a small prairie fire of interest but as of this morning the Windows users came alive and they’re going to try SDRAngel 3.5.5, too - so there’s momentum building there, too.
I agree that SDRAngel could be ‘lightened up’ to just perform frequency tuning, mode selection, and volume, squelch, and that would be ‘good enough’ for a headless/hardware controlled version of SDRAngel on a more portable platform (RPi, Odroid, Beagle, Arduino, etc). I think there’s a contingent of Hams that would welcome a version like that for field use but still use the mod/demod and other essential features of the existing build without a GUI. For that matter, a HW GUI could be used, too, that is less graphic intensive and just would require a 50 kHz scan of the active tuning region to display active signals without too much definition - more of a crude spectrum display than what’s there now. Again, I’m not asking you to do this, but if you can provide guidance some of us here with CVARC would like to start looking into it.
Again, both SDRAngel builds (Linux and Windows) are working GREAT…!! More to follow as there is more testing over the next 3 - 5 days…Stay tuned…
73 de Marty, KN0CK
2 Likes
Thanks Marty
1 Like
@vince48 - Vince,
There’s going to be a more definitive setup guide I’ll author on how to get SDRAngel setup on Linux and Windows such that anyone doing it for the first time won’t be startled or stopped by the process. I’ll be working on that over the next couple of days and will post here, but the WIn32 Windows version CAN be loaded and launched from a 64-Bit Windows OS from Win7 or Win10. The only prerequisite you need for the Windows install is the application Zadig that is commonly used to load the drivers of USB devices, and in this case is used for loading the Windows driver for the LimeSDR to play on USB 3.0 and run with other apps - especially SDRAngel. Once loaded from Zadig (and you keep Zadig open when the LimeSDR driver is loaded up), you then launch the Win32 version of SDRAngel and then allow it to come up. From there, there are Source (receive) and Sink (transmit) devices that have to be set up, demodulators (for receive) and modulators (for transmit) that are also set up from the SDRAngel GUI and then just establishing a few more variables (Sampling rate, NCO, FIR rate, LPF, Interpolation factor, Decimation factor, etc - some of those never really change) to have the LimeSDR function properly with the application. Once all that’s been done, you just click on the transmit button on the transmit GUI and you’re transmitting RF at the tuned frequency and modulating it with the modulator selected. Some would think that the GUI for SDRAngel is ‘too busy’ or has too many controls. I think Edouard did this for a reason such that one could fine tune their setup to the Lime - in time some of those controls (Sampling rate, interpolation, decimation, LPF, NCO) will go away eventually and be embedded in the application based on profiles that are selected - but for now they do allow A LOT of adjustment that are usually set once and you forget them.
Anyway, the app runs great on HF to (as @brendanthebig has observed himself) 23cm. I actually tested mine from 160m to 2m and it worked great - so Brendan just broke that barrier by taking it all the way up to near-microwave frequencies for checkout.
Do try the Windows build when you have a chance - it does work great and you will not be disappointed.
73 de Marty, KN0CK
If I remember correctly, I believe it can be done, but only by directly working directly in Limesuite as the soapy suds don’t seem to allow it at all . However, both Rx frequencies have to be close together.
It was quite a few months ago, but I think this is the Limesuite .ini file:
https://cdn.hackaday.io/files/20500877072000/Simple_806MHz_Bandwidth_30_Repeat_03.ini
… And this is the Limesuite Rx FFT:
1 Like
Marty,
one question…
Your friends are planning something similar to Portapack for HackRF or
something else for light LimeSDR field version?
73
Djani
1 Like
@9a4db - Djani,
Very close - I think the interface they’re looking for is similar to what PiHPSDR is using (and I’ve actually built for the Red Pitaya SDR) with optical/rotary encoders so there’s a knob for a major function. They’d like to get a crude spectrum display to show activity, but it’s not a hard requirement as well. The idea is to put a microcontroller that’s capable to communicating to the Lime via USB 2.0 (or 3.0 if it’s available) and just send commands to the LimeSDR when a function is affected, as well as work the I/Q stream for Rx/Tx. The microcontroller would have to have some sort of audio processing for transmit and receive audio but largely use what SDRAngel has for mod and demod. The mode selection would have to be more switchable than it is now such that when a mode selection is made it tears down the prior modulation and demodulation mode and instantiates the new mode - so that would be the largest change to what’s there now. Frankly, if the mode selection were like that now I think others would prefer that too - but the interface we have currently is fine.
The point to all this is to make the Lime field portable QRP but have the capability to operate from HF to SHF - that’s something that’s not currently available in ANY radio that’s out there (there are a number of club members who are UHF and SHF enthusiasts and have no interest in HF at all) - so that’s what makes this a good project to work on this winter and I, myself, am gearing up for it once I have my renovation done in November - - I’m taking a break from house construction and putting it all into this effort to make the Lime field portable.
Let me know if you have any other questions on this Dj - thanks for the ping -
73 de Marty, KN0CK
1 Like
Marty,
Definitely looking forward to the “definitive” guide in setup. One question, does using Zadig mess with the Windows drivers we use now for the Lime?
I’ve been working with 3.5.4 under Win 10.
I’m hoping John Melton can get back to work on support in the piHPSDR controller. I’ve been using a Tinker board in mine. Better performance than the pi.
Mike (another VHF/UHF/SHF nut)
1 Like
@N1JEZ - Mike,
I’ll be putting that together tomorrow as I have time away from the house renovation I’m doing in Belle Plaine. I’ll be setting that up for WIndows and Linux. I have noticed that when I use Zadig as the driver it tends to really screw up the driver arrangement for SDRConsole V3.0 and I have to ‘level-set’ all of that again. The two don’t play well together in terms of who ‘owns’ the driver (if it’s set up on SDRConsole and you use Zadig, then you lose it on SDRConsole until it’s reloaded for that app). Right now I have SDRAngel going on receive and transmit and haven’t tried looking at SDRConsole in awhile - maybe I should recheck that theory again and see if it still holds - - stay tuned on that.
I’ve been running PiHPSDR with my Red Pitaya and have been in the inside track of that since I know another Ham that is working directly with John Melton on the Tinkerboard update for PiHPSDR/Red Pitaya (I have one of those, too, and they do run spectacular on that setup) and I’ve also been poking this Ham to ask John when he’ll be supporting the LimeSDR, too. I’m told through that channel that ‘…anytime now…’ is the answer. His blog on supporting the LimeSDR on PiHPSDR that hasn’t moved in over a year, but I’ll take them at their word that they’re working this for the Lime. Again, my observation of the Red Pitaya running on Tinker with PiHPSDR has been nothing short of remarkable - it runs as well as my Flex 5000A does - maybe better since it’s two channels of receive…! Can you imagine having V/H/SHF on one channel of the two channel receive on PiHPSDR and be casually listening to HF on the other? God I hope that’s possible…
73 de Marty, KN0CK
1 Like
Great Marty,
I’ll hopefully see it Monday. This is the first weekend of the ARRL 10 GHz and up Cumulative, so I’ll be on Mountain tops this weekend with 10/24/47/78 GHz.
Mike
1 Like
Hello Marty,
about the “more switchable” mode selection I think it is a point where the software defined radios can radically part from their analog counterparts. In an analog radio you have one demod circuit for AM, another for FM and maybe another one for SSB with a control to select the side-band. Then of course you need a switch to connect the input of one of these circuits to the IF output. It is an entirely different story in software: you need a demod you just instantiate one of the required kind. You need another one in the same IF pass-band then you instantiate another one etc… You’re done with one you just delete it. This is incredibly flexible and expandable compared to an analog radio. The original authors had perfectly understood that and I continued in the same direction by adding more demods and then modulators too in the same concept of plugin instances. So I will definitely not change that. The UDP plugin has switchable demods but it is an exception.
Do not forget the presets. You can save an entire configuration of source or sink plugin and its channel plugins plus other arrangements of the UI in one preset. I have presets for the FM repeater band, the 40m SSB, UHF repeaters, Marine, Air etc… The list starts to be long and I have to also think of enhancing this facility a little bit to allow more levels of organization and maybe a search. This is a software radio and I don’t need one that resembles a HT or desktop RTx as I already have these.
Now a feature that would be really nice and allow a high degree of control and customization would be a REST API. Basically you would POST to trigger actions and GET to “see” what’s going on all this with a JSON interface. Thus you could control SDRangel entirely from a Python script for example with an interface of your liking. Internally this could be the base of the macro system with an embedded Python or other language interpreter.
At this moment I am piping Rx to Tx via UDP (this is the main “theme” of the next version). I have marine channel 16 FM exiting on 433 MHz ISM band in AM. Pretty useless but pretty cool. I think the only other option in software using a single program instance would be GNUradio or Pothos.
Best regards, Edouard.
1 Like
Id like the ability to use local FM repeaters
1 Like
@F4EXB - Edouard,
Thanks for the recent post. I have to agree, and I’ve become more appreciative, that the GUI you’ve built SDRAngel on has A LOT of capability to it and I’ve found that it’s very flexible toward other ranges and modes with all the available controls. I’ve also become more accustomed to the multiple demods running and just mute the demod I’m not using and just use the demod that I’m listening to - that is a handy feature. There are a lot of features that at first seemed like ‘too many controls for whats needed’ but as I have used SDRAngel I’ve come to appreciate why they’re there. Many other Hams may not have made this transition so quickly - while I now understand why those controls are there, others may still find the GUI challenging because of their familiarity with other GUIs and how they seem intuitive to use because - let’s face it, and as you’ve described, they all look alike. You’re branching out with a completely different user/GUI approach and I think some have not yet come to realize that different bands have different underlying settings and you’re given the power to the user to make those changes without you, the author, making that decision FOR us…frankly, I appreciate that.
So given all that, I would think if one was to use SDRAngel as the underlying app for a headless radio setup, then the approach would be to setup the receive and transmit with all the possible modulators and demodulators instantiated, tuned, and then available for use and then just ‘select’ them by muting the audio to everything that isn’t used and allow mic and speaker audio to be used from the mod/demod of choice. Is that a reasonable assumption? Please let me know for the purpose of SW architecture of this headless design.
Also, is there any budget for each modulator and demodulator that is instantiated to a target (portable) platform? What is the processor loading if one has all the normal modulators and demodulators (AM, FM, SSB) if just those six (3 modulators, 3 demodulators) are instantiated? Please let me know that, too, as the target for this will likely be the ASUS Tinkerboard (the RPi-clone that runs on the faster processor).
Please let me know your thoughts on this, Edouard, as I’m gathering this info as a means to prepare for that next phase of the development toward a headless SDRAngel design for portable LimeSDR field use.
Again, I appreciate all the hard work that’s gone into this, Edouard - without SDRAngel there would be a flood of LimeSDRs on EBay from all the Hams that would have given up by now - including me. SDRAngel has brought all the excitement back for LimeSDR being used for Amateur Radio HF to SHF.
73 de Marty, KN0CK
Hello Marty and all,
I have not made serious measurements on how much CPU load a mod or demod draws. It would be difficult to get something precise but one could get an idea. It also very much depends on the model of CPU. To get a rough idea though on how it goes with (really) portable stuff I have been successful in running SDRangel in a basic setup (one or a few channel plugins active) on a Pipo-X8 on Windows 8 and also on a Udoo-x86 Ultra on Linux Lubuntu 16.04. The last one is much more powerful and looks like the most promising and it also runs on any flavour of Linux unfortunately it is quite noisy RF wise. I couldn’t get anything practical with RPi3 on Raspbian. RPi3 can run on armv8 architecture with OpenSUSE but the stock version does not provide the drivers to run GPU acceleration so I didn’t go further. A few basic tests lead me to think that it could run twice faster on OpenSUSE than on Raspbian.
According to the profiling I made using perf or earlier with Valgrind the bulk of CPU power is consumed in decimators and interpolators more precisely in their filtering process. The filters are FIR kind of filters and they do intensive multiply+add with the “outermost” stages running at high speed.
The “mute” function does not disable all functions in fact the average power is still calculated to let you know if the channel is busy by lighting the mute button in green if above the squelch level. So there will still be some processing going on. The lighter approach would be to delete and re-create the channel plugin instance which does not necessarily takes a lot of time it is just not practical when doing things manually. Therefore a proper API is I think necessary to implement a headless solution or at least a light non-OpenGL approach. It is also a prerequisite to interesting internal features like the “macros” and many many possibilities with external control. So I think it is going to be the next big thing.
Best regards, Edouard.
Note on “muting” channel plugins: in fact all plugins should implement start and stop methods (these are pure virtual in the parent class BasebandSampleSink or BasebandSampleSource). These methods are called when the associated sample source or sink is started or stopped but maybe they could be controlled individually also.
1 Like
@F4EXB - Edouard,
Sorry for the long delay in getting back with you on the ‘headless’ design issues. I see that you’ve entered a web interface for SDRAngel, too, and that could suffice as a means to perform the more complex adjustments just by sending back status from a communication stream meant to look like a web interface from a browser. The commands/responses could just be streamed back to the headless interface to affect what’s being controlled to the LimeSDR via SDRAngel - that would be a great way of doing it that would also standardize it for actual Web use.
I appreciate the comments on the loading and some of the platforms that you’ve tested. I have an ASUS Tinkerboard running my Red Pitaya setup using PiPHSDR and it seems to work A LOT better than what you can use on RPi itself. The processor is much faster and it’s been designed to handle faster, more fluid, graphics as well (I’m not entirely certain of the specs, but I can tell you that high definition streamed video from Youtube or other sources looks as good as any video broadcast I’ve seen. You may want to try the ASUS Tinkerboard compling SDRAngel on their Debian release to see if it’ll work on the LimeSDR as well as it does with other systems. I wish I could try it on mine, but I have it committed to my Red Pitaya setup and don’t want to affect that right now - - I considered buying a second board and trying it - and I may still do that and see if it works. It would only be USB 2.0 since that’s all it supports, but I’ve heard of other using GQRX last year with the Lime on USB 2.0 and it worked fine (albeit a little sluggish).
I see your point about the muting of running demodulators and it might just be easier to just to destroy/create instead. Maybe the thing to do is wait to see how it’s implemented on a Web interface first…
Again, thanks for the update on the questions I had on SDRAngel - I think it’s great that this proposed Web interface is in the works and am anxious to see what comes of it. Please continue to keep us advised on your progress on that, Edouard.
73 de Marty, KN0CK
@N1JEZ - Mike,
I’m a little remiss in getting that ‘Definitive Installation Guide’ together because my week has been pretty hectic and will be through Friday - but I’m hoping to get some time on Friday night to make that happen or over the spare hours I have on the weekend (what spare time I do have getting my renovation moved along)…Stay tuned…!
73 de Marty, KN0CK
1 Like