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 On 06.08.2014 04:33, Vanush Vaswani wrote: > It might be Disk I/O is too slow. Try going from RTL-SDR source to Null > Sink. > > > > On Wed, Aug 6, 2014 at 7:46 AM, rejunte <engenhar...@recominte.com> wrote: > >> 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. >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
