SDRAngel Rx & Tx

Applications Amateur Radio
421

Agreed, this is excellent news and thanks to @IgnasJ for the fix!

1 Like
422

Thanks for pointing me in the right direction Andrew. Much appreciated.

423

@F4EXB @IgnasJ @andrewback

All is now good with Edouards latest release of SDRAngel (3.8.6) which is using the updated LimeSuite that IgnasJ made changes to rectify the problem of starting stream on LimeSDR Channel B. Many thanks to all involved.

Kindest regards,
Brendan Jenkins,
VK3WWB.

424

@F4EXB

Hi Edouard, I have started to play around with your WEB API examples. I am very much a novice when it comes to programming/scripting but I am having fun trying to work things out. I have tried the start_stop.py example and it is working great after fixing a minor syntax error in the script (line 23 :-otions.device_index = 0) . I do have a question for you that I can’t seem to work out by myself at this stage. In the limesdr_tx.py example, how do I set channel B (ie LimeSDR[0:1]) instead of the default channel A (ie LimeSDR[0:0]) ?

I have a lot to learn but I can see the powerful potential of your WEB API implementation. One benefit that I can see straight up is not needing to use the GPIO pins on the LimeSDR for sequencer and filter control as this can be done much easier directly from PC. Especially so with SBC’s that have Arduino capabilities built in.

Once again, thanks for all of your excellent work with SDRAngel.

Kindest regards,
Brendan Jenkins,
VK3WWB.

425

Hello Brendan,

the web API is still in proof of concept mode at this moment with quite a few plugins not yet supported. Some useful things can be made still as shown in the Python scripts examples. It will go full power with the release of version 4.

To select the second channel of a device you use the “streamIndex” key of the DeviceListItem structure of the JSON body of the request so the API call in the script becomes:

r = callAPI("/deviceset/1/device", "PUT", None, {"hwType": "LimeSDR", "tx": 1, "streamIndex": 1}, "setup LimeSDR on Tx 1")

Another big step is the server mode proof of concept which is at work for version 3.9.0

Best regards, Edouard.

1 Like
426

Thanks Edouard, I’ll try that tonight when I get home from work.

427

@F4EXB

Hi Edouard,

I tried the limesdr_tx.py script after making the changes to select 2nd channel of LimeSDR. I can’t get it to work on first attempt to run it. It does setup the Sink device ok (T1) and I can see the NFM modulator being added but it is not configured. Below is the output that I am getting.

Add Tx device set succeeded
{
“channelcount”: 0,
“channels”: [],
“samplingDevice”: {
“bandwidth”: 48000,
“centerFrequency”: 435000000,
“hwType”: “FileSink”,
“index”: 1,
“nbStreams”: 1,
“sequence”: 0,
“serial”: “”,
“state”: “idle”,
“streamIndex”: 0,
“tx”: 1
}
}
setup LimeSDR on Tx 1 succeeded
{
“deviceSetIndex”: 1,
“displayedName”: “LimeSDR[0:1] 0009061C02D12513”,
“hwType”: “LimeSDR”,
“index”: 2,
“nbStreams”: 2,
“sequence”: 0,
“serial”: “LimeSDR-USB, media=USB 3.0, module=STREAM, addr=1d50:6108, serial=0009061C02D12513”,
“streamIndex”: 1,
“tx”: 1
}
Get LimeSDR Tx settings succeeded
{
“deviceHwType”: “LimeSDR”,
“limeSdrOutputSettings”: {
“antennaPath”: 0,
“centerFrequency”: 435000000,
“devSampleRate”: 5000000,
“extClock”: 0,
“extClockFreq”: 10000000,
“gain”: 4,
“log2HardInterp”: 3,
“log2SoftInterp”: 0,
“lpfBW”: 5500000,
“lpfFIRBW”: 2500000,
“lpfFIREnable”: 0,
“ncoEnable”: 0,
“ncoFrequency”: 0
},
“tx”: 1
}
Patch LimeSDR Tx settings succeeded
{
“deviceHwType”: “LimeSDR”,
“limeSdrOutputSettings”: {
“antennaPath”: 1,
“centerFrequency”: 435000000,
“devSampleRate”: 3200000,
“extClock”: 0,
“extClockFreq”: 10000000,
“gain”: 4,
“log2HardInterp”: 3,
“log2SoftInterp”: 4,
“lpfBW”: 5500000,
“lpfFIRBW”: 100000,
“lpfFIREnable”: 1,
“ncoEnable”: 1,
“ncoFrequency”: -500000
},
“tx”: 1
}
Create NFM mod failed
{
“message”: “No channels for device set”
}

If I run it a second time (without changing anything in the SDRAngel GUI), it does manage to run but it also creates a second SINK with FileSink as device (T2) with no modulator added. Also, a second NFM modulator is added to the first SINK (T1) and it seems to be configured correctly and runs ok. I can see the morse code in the waterfall display. Below is the output from when I run it second time.

Add Tx device set succeeded
{
“channelcount”: 0,
“channels”: [],
“samplingDevice”: {
“bandwidth”: 48000,
“centerFrequency”: 435000000,
“hwType”: “FileSink”,
“index”: 2,
“nbStreams”: 1,
“sequence”: 0,
“serial”: “”,
“state”: “idle”,
“streamIndex”: 0,
“tx”: 1
}
}
setup LimeSDR on Tx 1 succeeded
{
“deviceSetIndex”: 1,
“displayedName”: “LimeSDR[0:1] 0009061C02D12513”,
“hwType”: “LimeSDR”,
“index”: 2,
“nbStreams”: 2,
“sequence”: 0,
“serial”: “LimeSDR-USB, media=USB 3.0, module=STREAM, addr=1d50:6108, serial=0009061C02D12513”,
“streamIndex”: 1,
“tx”: 1
}
Get LimeSDR Tx settings succeeded
{
“deviceHwType”: “LimeSDR”,
“limeSdrOutputSettings”: {
“antennaPath”: 0,
“centerFrequency”: 435000000,
“devSampleRate”: 5000000,
“extClock”: 0,
“extClockFreq”: 10000000,
“gain”: 4,
“log2HardInterp”: 3,
“log2SoftInterp”: 0,
“lpfBW”: 5500000,
“lpfFIRBW”: 2500000,
“lpfFIREnable”: 0,
“ncoEnable”: 0,
“ncoFrequency”: 0
},
“tx”: 1
}
Patch LimeSDR Tx settings succeeded
{
“deviceHwType”: “LimeSDR”,
“limeSdrOutputSettings”: {
“antennaPath”: 1,
“centerFrequency”: 435000000,
“devSampleRate”: 3200000,
“extClock”: 0,
“extClockFreq”: 10000000,
“gain”: 4,
“log2HardInterp”: 3,
“log2SoftInterp”: 4,
“lpfBW”: 5500000,
“lpfFIRBW”: 100000,
“lpfFIREnable”: 1,
“ncoEnable”: 1,
“ncoFrequency”: -500000
},
“tx”: 1
}
Create NFM mod succeeded
{
“NFMModSettings”: {
“afBandwidth”: 1000,
“audioSampleRate”: 48000,
“basebandSampleRate”: 200000,
“channelMute”: 0,
“ctcssIndex”: 0,
“ctcssOn”: 0,
“cwKeyer”: {
“loop”: 0,
“mode”: 0,
“sampleRate”: 48000,
“text”: “”,
“wpm”: 13
},
“fmDeviation”: 5000,
“inputFrequencyOffset”: 0,
“modAFInput”: 0,
“outputSampleRate”: 50000,
“playLoop”: 0,
“rfBandwidth”: 12500,
“rgbColor”: -65536,
“title”: “NFM Modulator”,
“toneFrequency”: 1000,
“volumeFactor”: 1
},
“channelType”: “NFMMod”,
“tx”: 1
}
Change NFM mod succeeded
{
“NFMModSettings”: {
“afBandwidth”: 1000,
“audioSampleRate”: 48000,
“basebandSampleRate”: 200000,
“channelMute”: 0,
“ctcssIndex”: 0,
“ctcssOn”: 0,
“cwKeyer”: {
“loop”: 1,
“mode”: 1,
“sampleRate”: 48000,
“text”: "VVV DE F4EXB ",
“wpm”: 13
},
“fmDeviation”: 5000,
“inputFrequencyOffset”: 0,
“modAFInput”: 4,
“outputSampleRate”: 50000,
“playLoop”: 0,
“rfBandwidth”: 12500,
“rgbColor”: -65536,
“title”: “NFM Modulator”,
“toneFrequency”: 600,
“volumeFactor”: 1
},
“channelType”: “NFMMod”,
“tx”: 1
}
Start device on deviceset R1 succeeded
{
“state”: “idle”
}

I’m not too concerned about it as I know you are still working on getting the WEB API sorted and it is currently experimental. Just providing some feedback which may help.

Kindest regards,
Brendan Jenkins,
VK3WWB

428

The first error you get is because the channel is added asynchronously by the thread running the main window triggered by the thread running the API. Then in the API it waits for 100ms and checks if a channel was added. I think that’s a bad idea and I will have to correct it. It has to return 200 after the message is sent with some data it has already available or just say “OK”.

The limesdr_tx.py script may not be idempotent. To make it more robust you would have to check the configuration of the SDRangel instance first and make decisions based on this. This API applies one of the most important RESTful principles requiring the API to be stateless. Similarly after adding a channel a second call should be made to verify that the channel was effectively added.

Edit: in that case it should return 202 and not 200 this has been corrected.

429

Thanks for the feedback Edouard. A lot of it I don’t understand yet as I am still very much at the novice/learning point in regards to programming/scripting. This is all part of the enjoyment though. Constantly learning new things and experimenting as is the true nature of Amateur Radio.

3 Likes
430

@brendanthebig - Brendan,

You’re ahead of me on the Web API and that’s something I want to tackle over the holidays when I have time to spare. I, too, think there’s a lot of potential in the Web API to put only those controls on the page that the user requires to make the GUI more simple for newer SDRAngel users. Us ‘power users’ are already comfortable with the GUI and can navigate around it without much difficulty, but it will be interesting to see how much is exposed in the Web API.

73 de Marty, KN0CK

1 Like
431

@F4EXB - Edouard,

I have a couple of questions regarding SDRAngel that you can surely answer since you’re the author of this great app. Here goes…

1.) Can the SDRAngel source be put into an environment to be compiled under Android to make SDRAngel compatible with higher end (faster) smartphones? I am interested in trying this but wanted to get your opinion on that before I went off on that tangent. Let me know when you have a chance.

2.) Is there a way to remove (or suppress) the QT GUI in SDRAngel and just have a ‘core’ running that can support the Web SPI - - a true headless design? Let me know on that as well, it’s a follow-up question for my first one.

Let me know on the above at your soonest, Edouard - thanks,

73 de Marty, KN0CK

432

Hi Marty,

Good to hear from you.

I think the SERVER version of SDRAngel that is due to come out soon will fit the bill. From my understanding, it will be GUI-less. Thus, we will be able to design our own remote GUI on whatever platform we desire. The CORE app will still need to run on reasonably powerful hardware such as LattePanda etc, with reduced requirements as the graphical side of things will be remote and up to the end user to program. I’m looking forward to collaborating with you on this front.

Kindest regards,
Brendan Jenkins,
VK3WWB.

433

I am thinking of things like external VFO dial, external PTT button, sequencer/filter control with tx inhibit until sequencer is in correct state etc etc…

1 Like
434

@brendanthebig - Brendan,

Yeah - those are on my list of things to put on a much simpler Web API form, too, and just fix all the other controls (sampling, LP Filters, etc) to values that won’t move. While you and I are used to the current GUI, my impression is that there are other Hams out there that just back away from the SDRAngel GUI because it’s just too intimidating to them and they’re all hanging back until SDRConsole V3.0 is complete - - what they’re not getting is that SDRAngel is even more feature-packed and adjustable than Console or other apps are and it’s giving them transmit RIGHT NOW instead of waiting for SDRConsole to finish development. If the Web API can help bring more Hams into the fold for SDRAngel and also make it easier to remote to as well, then that’s even better.

I’m planning to take some time either on Christmas Eve (earlier in the day) or after Christmas (when I’m not working on my renovation project in Belle Plaine) to take a hard look at the Web API and try to make a workable, simpler GUI for the masses, and I agree that a big part of this is collaboration (what makes sense to have on the form, and what doesn’t).

Stay tuned - there will be more on this as I have it…

73 de Marty, KN0CK

1 Like
435

Hello,

I have tried an Android build with Qt but I gave up. Qt code is supposed to compile and run on Android but I never succeeded in anything more than run the few simple examples provided by Qt.

Yes the server version is another binary that does not fire up the GUI and is independent of OpenGL and Qt Widgets. Then you need to deal with the web REST API to control the application. For my tests I use python or curl. For anything more fancy you would have to resort to a web UI framework such as Angular.io. REST APIs are very common and tons of examples of client/server applications can be found on the net. The API is also available for the GUI version and will serve as an external control or internal with a system call like a “macro”. The coming 3.9 version will implement a minimal version of the server as a proof of concept.

I have no idea at present of the system requirements for the server we’ll see. I hope that a Raspberry Pi 3 will be largely up to the job. Another point is that the server will be built for Linux only as I don’t see the point of running headless on Windows when tons of hardware are available for this purpose that run on Linux.

Edit: already with 3.8.6 except for Xenial you can get the API documentation online by using an invalid API entry point so simply http://127.0.0.1:8091 will do (default address and port).

Best regards, Edouard.

3 Likes
436

If anybody is having problems with old presets in newer/newest version of SDRAngel, it seems that Edouard has made some changes recently that impacts on presets (seems to impact NCO). I have been able to get my old presets to work correctly by loading them, making changes in settings to get things working then save the preset again. So far this has worked well on all of my old presets.

437

I may have reorganized the items order in the preset a bit although I did not notice a significant change in my presets. I am not sure the NCO is used very much with these presets however. As Brendan suggests not all of the preset is necessarily garbage so loading it, fixing it and saving it again will fix it for the next time.

On another note I have a minimal working server version running on a Rpi3 on openSUSE aarch64. Unfortunately openSUSE is not very good at audio and video and in fact there is no audio out with the Rpi3… Nevertheless running a simple receiver with a RTLSDR and one NFM demodulator seems to consume ~40% CPU averaged to a single core and 4% memory usage. The total CPU load on the machine barely exceeds 10% so this seems encouraging for remote headless work with the RPi3.

Note: sending audio samples via UDP shows it actually receives something and CPU load is increased to ~45% relative to one CPU.

Note2: to obtain a similar CPU load with a LimeSDR mini the host sample rate has to be down to 1.6 MS/s with a soft decimation of 8. Hardware decimation as expected has no incidence and can be increased to compensate for the relative low host sample rate.

Note3: I am still unable to run LimeSDR Mini in Tx with the RPi3. With sample rates as low as 1.6 MS/s CPU is up to ~220% and with 3.2 MS/s it is much less but it seems USB is unstable therefore I think it does not really communicate with the Lime hence the lower CPU.

Note4: Tx works fine with the HackRF at a sample rate of 2.6 MS/s. The CPU is fairly high for a simple NFM beacon and it is also irregular ranging from 50 to 95% (still relative to one core). The Tx chain does not use the same FIFO as the Rx chain and it is possible that it is not performing as good as the Rx. I don’t remember if the issue was raised in this thread but I remember someone else noticing it.

Note5: I eventually succeeded in getting something out of the LimeSDR mini in Tx on the RPi3 at 2.5 MS/s (it does not seem to accept lower rates). It seems I used the wrong antenna port for ~435 MHz (port #2 is better). CPU load is comparable to the HackRF at a close rate at ~72%

3 Likes
438

Please note that I have created a discussion group for SDRangel on groups.io: https://groups.io/g/sdrangel

2 Likes
439

joined :wink:

440

I currently have a problem with my LimeSDR while using SDRAngel. Streaming randomly stops (ie, USB data stops). It doesn’t matter what demod I am using or if NCO is in use or not. I don’t think the problem is with SDRAngel as I have tried older known good versions and get the same problem still. I think it may be an issue with the latest firmware/gateware. As yet I have not downgraded the firmware/gateware to confirm this. I was just wondering if any one else is having similar problems ??
I’ll try downgrading the firmware/gateware later today and report back with my findings.

1 Like