gmane.comp.hardware.beagleboard.sdr

Re: USRP Embedded

Philip Balister — 2010-09-13T20:28:24

Sorry for be slow replying, we are working very hard on the USRP 
Embedded. Sorry about the photo, I should be able to post a better one 
soon though. More news as it becomes available.

Philip

Re: USRP Embedded

tusam — 2010-08-27T16:37:04


Hi, I'm also very interested to see it happen, any news on this front?
Could you btw upload the photos to a photo service (like picasa)? Machine behind
the dyndns address hasn't been reachable for a while.

-Samuli

Re: Error while building GNU Radio on Beagleboard.

Ashwin Raut — 2010-07-06T11:46:16

Adding swap space of upto 1.5 gb helped.I was able to build GNU Radio. Make
ran successfully.Thanks.

Meanwhile
"make check" gave me this error:

..terminate called after throwing an instance of 'std::invalid_argument'
  what():  data length must be a multiple of vlen
Aborted
FAIL: run_tests



Error Log:

make  check-TESTS
make[4]: Entering directory `/home/root/gnuradio/gnuradio-core/src/tests'
Testing gr_vmcircbuf_createfilemapping_factory...
gr_vmcircbuf_createfilemapping: createfilemapping is not available
....... gr_vmcircbuf_createfilemapping_factory: Doesn't work
Testing gr_vmcircbuf_sysv_shm_factory...
gr_vmcircbuf_sysv_shm: shmat (2): Invalid argument
....... gr_vmcircbuf_sysv_shm_factory: Doesn't work
Testing gr_vmcircbuf_mmap_shm_open_factory...
....... gr_vmcircbuf_mmap_shm_open_factory: OK
Testing gr_vmcircbuf_mmap_tmpfile_factory...
....... gr_vmcircbuf_mmap_tmpfile_factory: OK
gr_vmcircbuf_createfilemapping: createfilemapping is not available
gr_vmcircbuf_sysv_shm: shmat (2): Invalid argument

Re: libstdc++ error while building GNU Radio on Beagleboard.

Charles R — 2010-07-05T02:23:04

lib/
error:


i rerun configure after removing all la files and did make i got this error:

Making all in .
make[5]: Entering directory `/home/root/gnuradio/gnuradio-core/src/lib'
make[6]: Entering directory `/home/root/gnuradio'
make[6]: Leaving directory `/home/root/gnuradio'
/bin/sh ../../../libtool --tag=CXX   --mode=link g++ -Wall -Woverloaded-virtual 
-march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -pthread  -
version-info 0:0:0 -release 3.3.1git  -o libgnuradio-core.la -rpath 
/usr/local/lib bug_work_around_6.lo filter/libfilter.la g72x/libccitt.la 
viterbi/libviterbi.la general/libgeneral.la gengen/libgengen.la io/libio.la 
missing/libmissing.la reed-solomon/librs.la runtime/libruntime.la 
hier/libhier.la /home/root/gnuradio/gruel/src/lib/libgruel.la -lfftw3f -lm   -
lgsl -lgslcblas -lm   -lgslcblas 
grep: /usr/lib/gcc/arm-angstrom-linux-gnueabi/4.3.3/../../../libstdc++.la: No 
such file or directory
/bin/sed: can't read /usr/lib/gcc/arm-angstrom-linux-
gnueabi/4.3.3/../../../libstd

Re: USRP Embedded

Philip Balister — 2010-07-04T21:35:55

Yes.

Philip

Re: USRP Embedded

Alexandru Csete — 2010-07-04T21:33:57

Wow, amazing! Something like this has been on my wish list for quite some time.
The little board mounted on the large board, is that a Gumstix Overo?

Alex

USRP Embedded

Philip Balister — 2010-07-04T18:38:18

Ettus research was showing this at the European Reconfigurable Radio 
Technology Workshop.

http://balister.dyndns.org:8008/~balister/img_0819.jpg

I'm working on the FPGA to ARM device driver for them.

Philip

Re: libstdc++ error while building GNU Radio on Beagleboard.

Philip Balister — 2010-07-04T18:35:29

Try rerunning configure after removing all the la files you can find.

Philip

libstdc++ error while building GNU Radio on Beagleboard.

Charles R — 2010-07-04T17:32:09

Hi,

while building GNU radio on beagleboard , i encountered libstdc++ error, 
At first it was 
Cannot find libstdc++.so in /lib/ i copied libstdc++.so from /usr/lib/ to lib/ 
but the file was 0 bytes.
I didnt see this error again but then after doing make i got following error:

*****Error Log **************************************************************

libtool: link: ( cd ".libs" && rm -f "libgnuradio-core-qa.la" && ln -s 
"../libgnuradio-core-qa.la" "libgnuradio-core-qa.la" )
g++ -DHAVE_CONFIG_H -I. -I../../..   -I/usr/include -
I/home/root/gnuradio/gnuradio-core/src/lib/runtime -
I/home/root/gnuradio/gnuradio-core/src/lib/general c
mv -f .deps/gnuradio-config-info.Tpo .deps/gnuradio-config-info.Po
/bin/sh ../../../libtool --tag=CXX   --mode=link g++ -Wall -Woverloaded-virtual 
-march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -pthread   -o  
libtool: link: g++ -Wall -Woverloaded-virtual -march=armv7-a -mtune=cortex-a8 -
mfpu=neon -mfloat-abi=softfp -pthread -o .libs/gnuradio-config-info gn

Re: Error while building GNU Radio on Beagleboard.

ILKYOUNG KWOUN — 2010-07-03T06:16:57

Hello, Ashwin,

I've encoutered similar problem when I tried to native-compile a 3D graphics
tool called 'Panda3D'. As Philip said above, adding swap memory will solve
the problem.
You can either make a swap file in your filesystem or add a swap partition.

As for me, I tried with extra storage in my 8G SD card first. Later I
thought that frequent read/write access of the swap operation on SD card
might slow down the compilation performance further. So, I used a 40GB usb
hard disk instead of swap partition on the SD card. I did not measured the
performance quantatitively but it seemed to be a bit faster.

Moreover, while I compile the program throughly(It took more than 30 hours
in total. A long journey!), I found that some objects generated were
corrupted. I did not track down the problem exactly but I was pretty
suspicous on the writing lag to the SD card. (Once you do any file operation
on the SD card, you should type 'sync' not to loose the changes.) So, I
eventually moved all the codes to compile to the

Re: Error while building GNU Radio on Beagleboard.

Philip Balister — 2010-07-02T05:08:15

We've been building gnuradio on the beagle because we can. Most of the 
time. For small changes it is "easier", after the initial build.

However, lately people have been running into the OOM killer. I'm told 
adding swap will help.

When I get back from Germany, one of my tasks is to set up a cross tool 
chain so we can easily develop code quickly. The idea is to have OE 
generete the cross sdk for us including all the supporting libraries.

Philip

Re: Error while building GNU Radio on Beagleboard.

Ashwin Raut — 2010-07-02T04:38:59

Yes , i am building GNU Radio on Beagleboard.
Which recipe would be better to cross compile and to have grc.
Do i have to  cross compile every time to add a custom blocks in GNU Radio ?


My df -h output on beagleboard is as follows.
Filesystem                Size      Used Available Use% Mounted on
/dev/root                 1.4G    651.4M    727.6M  47% /
none                     49.4M    124.0K     49.3M   0% /dev
/dev/mmcblk0p2            1.4G    651.4M    727.6M  47% /media/mmcblk0p2
/dev/mmcblk0p1          399.2M      3.1M    396.1M   1% /media/mmcblk0p1
tmpfs                    49.4M     44.0K     49.4M   0% /var/volatile
tmpfs                    49.4M         0     49.4M   0% /dev/shm
tmpfs                    49.4M         0     49.4M   0% /media/ram

Thanks,
Ashwin Raut.

On Thu, Jul 1, 2010 at 9:18 PM, George Schaertl <gschaertl-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

Re: Error while building GNU Radio on Beagleboard.

George Schaertl — 2010-07-02T04:18:32

Looks like the low memory killer. Are you trying to build GNU Radio on
the BeagleBoard? If so, cross-compiling will save a lot of time in the
end.

Error while building GNU Radio on Beagleboard.

Ashwin Raut — 2010-07-02T03:33:45

Hi,

I got the following error while building GNU Radio , i tried to search
for the error it said something about swap space in some ubuntu forums,
but i am not sure if its the same issue on beagleboard.

Console Log:

Making all in .
make[5]: Entering directory `/home/root/gnuradio/gnuradio-core/src/lib'
/bin/sh ../../../libtool --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H
-I. -I../../..   -I/usr/include
-I/home/root/gnuradio/gnuradio-core/src/lib/runtime c
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../../.. -I/usr/include
-I/home/root/gnuradio/gnuradio-core/src/lib/runtime
-I/home/root/gnuradio/gnuradio-coreo
mv -f .deps/bug_work_around_6.Tpo .deps/bug_work_around_6.Plo
/bin/sh ../../../libtool --tag=CXX   --mode=link g++ -Wall
-Woverloaded-virtual -march=armv7-a -mtune=cortex-a8 -mfpu=neon
-mfloat-abi=softfp -pthread  -ver
libtool: link: g++ -shared
-nostdlib /usr/lib/gcc/arm-angstrom-linux-gnueabi/4.3.3/../../../crti.o
/usr/lib/gcc/arm-angstrom-linux-gnueabi/4.3.3/crtbeginS.o0
[70258.842254] select 1

Re: Beagle Board Performance

Sylvain AZARIAN — 2010-06-22T09:15:31

Devin,

Then you are not taking the problem from the right perspective...
First, you have to know the bandwidth you need for your application ( mainly
"fmax"). This will define your sampling rate.
Then, you have to set your decimation factor depending on the amount of data
resulting from the previous choice. On a "fast" pc running Linux, an avg
around 30 msps can be achieved. Not tested with Beagleboard yet.

Then.... processing : you need to have one thread reading the USB stream
from the USRP and filling a buffer. you need a second thread performing the
fft and doing the decision.
the good question now is : what is the frequency resolution you need ( this
will set the fft size .... and time needed to compute that).

I would suggest you start by estimating FFT size, then evaluate the time you
have to compute that.
But maybe I am completely wrong and in fact you do not need real time
processing... ????

sylvain

2010/6/21 devin kelly <dwwkelly-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>

Re: Beagle Board Performance

devin kelly — 2010-06-21T17:12:57

Sylvain,

Sorry for not being clear.  I was just trying to say that, the higher the
decimation rate the more data I have to process, I wasn't talking about
decimating twice.

So would I'd like to do is record samples for 0.5 to 0.75 seconds (for
example), then do some processing on those samples for the remaining, 0.25
to 0.5 seconds, and repeat.  The processing I'm thinking of is taking an
FFT, making a decision, then recording it to non-volatile storage.  So my
question is, to do processing like I described, what sort of decimation
rates can I choose?

Devin

On Mon, Jun 21, 2010 at 9:01 AM, devin kelly <dwwkelly-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

Re: Beagle Board Performance

Sylvain AZARIAN — 2010-06-21T13:10:16

The decimation process is done in the FPGA inside the USRP1.
Why are you trying to redo that outside ? It is intended to reduce the
bandwith over the USB...

Regards
Sylvain Azarian
www.tools4sdr.com

2010/6/21 devin kelly <dwwkelly-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>

Re: Beagle Board Performance

devin kelly — 2010-06-21T13:01:54

What about a more reasonable decimation rate, like 32 or 64... Could I
collect samples 50%-75% of the time and then process that data the rest of
the time?

Thanks again,
Devin

On Fri, Jun 18, 2010 at 10:09 AM, devin kelly <dwwkelly-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

Re: Beagle Board Performance

Philip Balister — 2010-06-18T14:46:57

It is possible. There is a Google SoC project to improve fftw support 
for the beagle. See http://elinux.org/BeagleBoard/GSoC/2010_Projects.


Decimation rates of 8 will be hard. Especially getting data from USB.

Philip

Beagle Board Performance

devin kelly — 2010-06-18T14:09:17

Hello,

I'm interested in doing a project with the Beagle Board and the USRP1, along
with using gnu radio.  My lab doesn't have a Beagle Board or USRP1 (only
USRP2s), so I need a few questions answered before I commit to this
platform.

What type of performance can I expect from the Beagle Board?  I'm mostly
interested in doing FFTs with some comparatively small processing on that
data, is this possible?

What sort of decimation rates can I use and expect near real time
performance for this application?  I have a few (albeit several years old)
machines that struggle with just taking an FFT with a decimation rate of
around 8.  This is on the USRP2 as well.

Any advice at all is appreciated.
Devin

Need a clue to solve a Boost inconsistency under Angstrom

Stephen Hersey — 2010-05-23T02:09:17

I'm attempting to build OSSIE using the Bitbake build system for the
BeagleBoard. I've successfully built the Angstrom x11-image
(local.conf lists DISTRO = "angstrom-2008.1") on my cross-build system
(running Debian Lenny updated a week ago), so I trust the basic sanity
of my OE toolchain and the basic Angstrom build.

I've followed the instructions at "Getting started with Embedded SDR"
(http://www.opensdr.com/node/7), with adaptations that seem reasonable
for the latest bitbake, mainly replacing ${OEDIR} with ${OETREE}. (I
notice those instructions date from 2008, so there may be something
else obsolete I'm doing...) I have also compared them to the Overo
build instructions, and I don't see any obvious incompatibilities.

The OSSIE version I'm getting from the SVN repo at
https://svn.geekisp.com/opensdr/OE/ossie_collection is 0.7.0.0, tagged
as ossie-cf-0.0.0+svnr380-r2.

When I try to bitbake a console-image with the OSSIE collection
included, I get an error compiling the OSSIE CF, which seems to be an
in