I have been doing some tx testing in sdrangel over the last couple of days. I have been checking cpu usage while doing these tests. I have noticed that during tx, sdrangel is using a single cpu core. I managed to get 6 NFM modulators to work (had to drop samplerate to 2mb/s) before cpu core maxed out to 100%. During rx, the load is spread across all cores. Is this done intentionally to get timing issues for tx working properly or is there an option to spread modulators across cores. If it is possible, it may help in peoples attempts to get sdrangel working on reasonably powered sbc’s with acceptable results.
does it still run on a single CPU with 6 modulators (gee!) in parallel? There should be at least the main thread and one thread for the modulator and possibly one for the “sampling” device. I have to check on my side also… Thanks for reporting.
So far I have only tested it under Ubuntu 17.04…I’ll try it out on windows tonight and see if I get the same result…I will report back with my findings.
there is still a long way to go since to be implemented properly the model-view pattern should be implemented everywhere. It should not be too difficult with the plugins where segregation is more or less done already but things look much more entangled in the main application / main window. Thus the web interface will be seen like just another user interface (view). It will also help to build a true headless (server) version. I think it will have to go a few intermediate releases before the big release.
Anyway it is through this kind of impulse with the contributions of all of you guys that this SDR can get better.
Also thanks for mentioning the ASUS tinker board. I might add it to my SBC collection. I already make a Debian 9 build for x86 so it should be feasible to get it running for ARM.
I have tested sdrangel on one of my win10 machines. TX multi-threading seems to be working fine under windows. I’ll give it another go on my Ubuntu 17.04 machine to see if I can replicate the problem. I’ll get back to you with my results shortly.
Edouard, I have done further testing and have found that multi-threading is working fine on Ububtu 17.04 with up to 2 NFM modulators. Once I set 3 or more NFM modulators, everything seems to be running from the one core (it does swap from core to core but only 1 core is running close to 100% at any time, the others are idling). I managed to get up to 3 nfm modulators to work on win10 and multi-threading was still ok. I could not get it to work with any more than 3. It could be the pc I am using as it is a much older i5 than my main pc with Ubuntu 17.04 on it.
in fact I haven’t done many tests with multiple modulators as it tends to be impractical somehow due to the necessary mixing of sources. This will in general lead to a large peak to average ratio on the resulting RF signal and a better option is to use several transmitters and mix them in RF with a combiner or diplexer.
In fact this mxing might be the cause because it creates a single point running in one thread where the samples of all other threads must be collected one by one. Depending on how the O/S sees that situation it may decide to put all threads on the same CPU. Of course that’s just a guess.
For all these reasons the program issues a warning message that you probably noticed when you instantiate another Tx channel.
On Rx you don’t have the issue because the samples are distributed in chunks in turn to all demodulators. Perhaps on Tx side the mixing stage could prefetch samples from the modulators. This doesn’t change the peak/average issue in RF though.
it would be fine and easier to set, if the NFM and SSB Demodulator would have sliders for Vol and Sq (like WFM or Broadcast FM) instead of the turn-knobs (would be at least more consistent)
Maybe but sliders take a lot of space and the real estate is tight so I think I’m not going to change that. What I usually do is point with the mouse at the button and use the wheel to turn the knob. This allows to tune in fine steps.
Apologies for the late reply.
Running on Linux - openSUSE Tumbleweed x86_64.
lancelot@slipstream:~> rpm -q limesuite sdrangel gqrx gnuradio
limesuite-17.06.0-1.3.x86_64
sdrangel-3.5.5-1.1.x86_64
gqrx-2.7+git.20170819-1.1.x86_64
gnuradio-3.7.11-13.52.x86_64
I have got further but must admit I cannot figure out the frequency settings for RX.
e.g:- Main center frequency in KHz – 0.030.000. The “3” won’t go any lower.
I set the NCO to give a difference frequency of 3.697MHz.
From that picture you would increase SR Sample rate and LP low pass filter beyond 30,000 and set NCO to 3.679.
Use the software decimation to zoom in and out. Drag the display section with those settings in it down a little and it will reveal the antenna selection and gain controls.
As Lance (@Axeman) has mentioned, setting the sampling rate up will lower the frequency that you can operate at - I always set it between 6.000.000 and 7.000.000 and Lance is also right about setting the LP to 30 MHz, too - that’s critical. Other than that your interpolation and Decimation settings look right - try that and let us know how you get along. You should be able to tune into the AM broadcast band with sampling set up higher.
Thanks, Marty, for making that more clear. Not enough coffee in me yet this morning. We should have mentioned that a low pass filter is important to add to the antenna input to filter all of the FM broadcast and wireless devices that are overpowering everything and desensitizing the LNA. I turn off my cellphone while I am using the SDR for HF.
I also just noticed the NCO button was not “lit”. It needs to be selected.
I meant to mention this, too, on my earlier reply - - When running SDRAngel with a demodulator and modulator set up on one channel you will find that there will be interaction in the sampling between the two (mod/demod) - they won’t have independent settings. So best to use a sampling rate something around 5.000.000 to start and then increase the value such that you get best resolution in receive and your transmit sounds good, too (these days the transmit is pretty forgiving on sampling rate). Just so you know -
NCO is the actual frequency, not an offset here. You would set it to 0,000,198. That is a button to the left labeled “NCO” that must be clicked on. Up your sample rate x10. drag down the dots (…) under LP and FIR to make sure you have the right antenna selected. W is what you should be using. Clicking the DC button on will get rid of most of the center spike.
Sid, i usally set automatic gain and turn the dial untill i see something reasonable, then set it on manual and adjust the gains slowly trying to maximize the signal-to-noise ratio
Hope you are not far from that transmitter, and within LW surface wave range,
have RX input modification and some LNA for that low freq.
Speaking from own experience on modified RX1_W + LNA4HF
73
