Is gnuradio able to run on Ubuntu Touch?
I want to use my tablet with gnuradio and rtl-sdr. Do you guys think its
possible with Ubuntu Touch? Or there is another way to do it?
Thanks
Regis
–
View this message in context:
http://gnuradio.4.n7.nabble.com/gnuradio-on-ubuntu-touch-tp49315.html
Sent from the GnuRadio mailing list archive at Nabble.com.
Hi Regis,
I don’t know anything about Ubuntu touch. But if it’s a proper linux,
then yes, GNU Radio will run on it, probably.
The question is however if your tablet is powerful enough to do
something useful with the data, since we tend to use strong computers to
do realtime signal processing.
Greetings,
Marcus
Hi Marcos, thank you for your reply.
What would be the minimum required configuration for a computer to run
gnuradio without problems?
Regis
–
View this message in context:
http://gnuradio.4.n7.nabble.com/gnuradio-on-ubuntu-touch-tp49315p49325.html
Sent from the GnuRadio mailing list archive at Nabble.com.
Running Linux 
The thing is that GNU Radio is but a framework, and has little
computational overhead; the load you are seeing is primarily defined by
the signal processing you do, so I can’t answer that question.
I like to bring up a analogy: It’s like asking what the minimum
requirement for playing games on a computer is. If you’re only playing a
text-based adventure, then a graphic calculator will be fine; if you’re
aiming for photorealistic graphical effects, you will need something
more beefy.
With best regards,
Marcus
It might be Disk I/O is too slow. Try going from RTL-SDR source to Null
Sink.
Hi Marcus, back to this discussion after a few tests.
I decided to try RTL-SDR and GNU Radio on a Single Board Computer.
I’m currently using the Banana Pi which is a ARM Cortex-A7 dual-core,
1GHz,
Mali400MP2 GPU, 1GB DDR3 DRAM, using a debian based system.
The first thing I tried was just a simple RTL-SDR Source to File Sink -
just
saving the receiving data to a file at 2e6 sample_rate.
The problem is that I get the “0” characters on the terminal indicating
overflow status.
I don´t know if I’m doing something wrong or if the banana pi can´t
handle
real-time signal process.
What do you think about that?
–
View this message in context:
http://gnuradio.4.n7.nabble.com/gnuradio-on-ubuntu-touch-tp49315p49773.html
Sent from the GnuRadio mailing list archive at Nabble.com.
On 08/06/2014 04:56 AM, Marcus M. wrote:
overhead, which includes at least one copy from libusb/rtl-sdr buffer
Greetings,
Marcus
Also, the rPI (and clones) is a pretty-anemic CPU. Think of it as being
about 1/5th to 1/8th as powerful as your garden variety desktop X86
machine.
I think the culprit here is a mix, though, as Marcus M. says.
Even a class-10 SD card is about 1/5th as fast as a good hard disk or
SSD.
We don’t have much optimization for ARMs yet, and I assume that the
rtl-sdr source somewhere has to convert from whatever comes through USB
into floats. Furthermore, USB2 bulk transfer has a maximum packet length
of 512B [citation needed], which would at an assumed 2B/complex equal
but 256 == 2^8 Samples/package. Now let 1MS/s \approx 2^20 S/s = 2^12
USB packets per second. That can be lot for a CPU running at 1GHz,
because a USB handler in the Kernel has to handle each of them, they
have to be put through libusb (which is luckily very efficient) and then
converted by rtl-sdr/gr-osmo into something that your flowgraph can deal
with. Then you get the GNU Radio scheduling overhead, which includes at
least one copy from libusb/rtl-sdr buffer to a GNU Radio buffer, and
then you get the filesystem overhead, which can be significant depending
on what kind of file system you use. Then you get the overhead of
accessing the storage device. I don’t know the banana pi, but I’d take a
chance and say it’s a USB storage device, so you get the same hassle as
on the RTL dongle side, but on this side with higher data rates. Or, you
are storing to an SD card, which could simply be too slow, as Vanush
correctly assumes (trick: most SD cards today have a “Class N” printed
on them; that’s a usually slightly exaggerated multiplicator for a 2MB/s
write rate.
Greetings,
Marcus
I tried what Vanush said and just connected RTL-SDR Source to a Null
Sink and
got no overflows.
I’m using a class 10 sd card, that must be the problem.
I did some demodulation with no problem, but when I add a Low Pass
Filter,
the overflow happens again.
Would the filter do the same thing as the file sink and buffer the data
causing the overflow?
–
View this message in context:
http://gnuradio.4.n7.nabble.com/gnuradio-on-ubuntu-touch-tp49315p49799.html
Sent from the GnuRadio mailing list archive at Nabble.com.
On those single board computers I don’t bother writing to SD. I just
route
it through the network (assuming large enough bandwidth) to another
graph
or Python script that dumps it to a disk with faster storage bus.
You can use gr-zmqblocks for that.
On Wed, Aug 6, 2014 at 11:51 PM, Marcus Müller
[email protected]
The overflow is not a result of buffering; in fact, buffering helps.
overflows happen because at any bottleneck in your processing chain,
samples start to stagnate, causing back pressure. When all buffers are
filled, there’s nothing the rtl source can do but drop samples. That’s
an overflow.
A computationally intense filter might also lead to overflows, but here
it’s because your CPU can’t keep up with the sample rate, whereas with
the file sink, your storage can’t sustain the write rates.
Greetings,
Marcus
I actually don’t need to write to a file. I just did to test the
hardware (I
thought writing to a file would be the most simple task).
What I really want to do is demodulate the signal and measure the signal
strength. That seems to be working fine (no overflows) as long as I
don’t
use a filter on the RTL-SDR Source.
–
View this message in context:
http://gnuradio.4.n7.nabble.com/gnuradio-on-ubuntu-touch-tp49315p49802.html
Sent from the GnuRadio mailing list archive at Nabble.com.
Sample rate → 2M
cutoff → 135k
transition width → 10k
–
View this message in context:
http://gnuradio.4.n7.nabble.com/gnuradio-on-ubuntu-touch-tp49315p49804.html
Sent from the GnuRadio mailing list archive at Nabble.com.
Try making the transition width sloppier, like 50k
On 2014-08-06 10:17, rejunte wrote:
Links:
What are the parameters of your filter? Sample rate, cutoff, and
transition width?
On 2014-08-06 10:08, rejunte wrote:
Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page [2]
Links:
Tried that, but still ocurring overflow.
Another thing I had was that on my computer I was using a
complex to mag^2 → single pole IIR filter → log10 → multiply const
(10)
to measure the signal strength
that is also causing overflow on the single board computer. If I put a
RMS
block instead, no overflow occurs.
–
View this message in context:
http://gnuradio.4.n7.nabble.com/gnuradio-on-ubuntu-touch-tp49315p49807.html
Sent from the GnuRadio mailing list archive at Nabble.com.
Try decimating after the filter, before you start computing log10 at the
input rate. There’s no need to do those calculations at the original
sample rate once you’ve computing complex-to-mag**2 and filtered.
On 2014-08-06 10:30, rejunte wrote:
–
View this message in context:
http://gnuradio.4.n7.nabble.com/gnuradio-on-ubuntu-touch-tp49315p49807.html [1]
Sent from the GnuRadio mailing list archive at Nabble.com.
Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page [2]
Links:
doing your computations on a reduced sampling rate always makes a lot of
sense.
Also, if you do complex to mag? prior to filtering, you get the power in
the overall nyquist band ignoring power fluctuations that do not pass
the low pass, and not the power in the pass band of the filter.
Example: Assume we have a complex sine at frequency $f>f_\text{cutoff}$
$s(t) = e^{2\pi j f t}$. It has a constant mag? of $|s|^2 = 1$.
Now, the low pass of a constant 1 is still 1.
Now, let’s low pass first with a filter $h(t)$ and then mag?. Assume
filter stop band attenuation is infinite, then $r(t) = h(t) * s(t) = 0$
because $f>f_\text{cutoff}$. It follows that $|r|^2 = 0 \neq 1$.
Yet another side note: have a look at the polyphase filter banks (PFBs)
that are relatively new in GNU Radio, if you want to process multiple
sub-bands at once.
Greetings,
Marcus
That seems to be a little bit better. Still causing overflow
occasionally,
but I can work with it.
But still can’t use the first low pass filter without overflow
–
View this message in context:
http://gnuradio.4.n7.nabble.com/gnuradio-on-ubuntu-touch-tp49315p49816.html
Sent from the GnuRadio mailing list archive at Nabble.com.
The first filter is a low pass filter connected to the RTL-SDR Source.
After this filter I demodulate the signal and compute the signal
strenght
–
View this message in context:
http://gnuradio.4.n7.nabble.com/gnuradio-on-ubuntu-touch-tp49315p49818.html
Sent from the GnuRadio mailing list archive at Nabble.com.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs