Re: [Discuss-gnuradio] Master build failure for ARM when building cross

[Almohanad Fayez]

Philip, this is problem of no help but I ran into this issue when I was
still using ubuntu 10.04, I found a reference where Marcus was having the
same problem but on ubuntu 12.04

http://lists.gnu.org/archive/html/discuss-gnuradio/2013-02/msg00178.html

where I applied the recommended changes and added some other mods
recommended by Josh but I couldn't fix it I ended up upgrading from 10.04
to 12.04 and everything worked.

My suspicion, and again I'm probably the wrong person to comment on this,
is that it was a swig/python version issue 10.04 was running Python 2.6 I
don't remember what swig version and 12.04 is running Python 2.7 and swig
2.0.4.  I would recommend experimenting with alternative swig versions and
see if the problem goes away.

al fayez

On Thu, Apr 18, 2013 at 9:38 PM, Philip Balister wrote:

> Any ideas? I haven't looked at it hard yet.
>
> Philip
>
> eglibc/sysroots/ettus-e200/usr/include-fvisibility=hidden
> -Wsign-compare -Wall -Wno-uninitialized -o
> CMakeFiles/test-gr-blocks.dir/qa_gr_block.cc.o -c
>
> /home/balister/src/oe-core/build/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gnuradio/3.6.4.1-r0/git/gr-blocks/lib/qa_gr_block.cc
>
> /home/balister/src/oe-core/build/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gnuradio/3.6.4.1-r0/git/build/gr-blocks/swig/blocks_swig0PYTHON_wrap.cxx:7083:22:
> error: redefinition of 'struct swig::traits'
>
> /home/balister/src/oe-core/build/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gnuradio/3.6.4.1-r0/git/build/gr-blocks/swig/blocks_swig0PYTHON_wrap.cxx:6345:22:
> error: previous definition of 'struct swig::traits'
>
> /home/balister/src/oe-core/build/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gnuradio/3.6.4.1-r0/git/build/gr-blocks/swig/blocks_swig0PYTHON_wrap.cxx:7087:23:
> error: redefinition of 'struct swig::traits_asval'
>
> /home/balister/src/oe-core/build/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gnuradio/3.6.4.1-r0/git/build/gr-blocks/swig/blocks_swig0PYTHON_wrap.cxx:6349:23:
> error: previous definition of 'struct swig::traits_asval'
>
> /home/balister/src/oe-core/build/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gnuradio/3.6.4.1-r0/git/build/gr-blocks/swig/blocks_swig0PYTHON_wrap.cxx:7093:23:
> error: redefinition of 'struct swig::traits_from'
>
> /home/balister/src/oe-core/build/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gnuradio/3.6.4.1-r0/git/build/gr-blocks/swig/blocks_swig0PYTHON_wrap.cxx:6355:23:
> error: previous definition of 'struct swig::traits_from'
>
> /home/balister/src/oe-core/build/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueab:
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>



-- 
Almohanad (Al) Fayez
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] PSK modulation (along with packed vs unpacked bytes)

[Almohanad Fayez]

Thanks for the update Nathan, I've actually been trying to figure out where
the payload reassembly occurs.

Al Fayez
On Mar 22, 2013 6:26 PM, "Nathan West"  wrote:

> I've done a lot of code reading the last 2 weeks and worked on a custom
> PSK modulator (basically hierarchical 2/4psk). I've tested it at baseband
> on everything seems good, so I'm hoping now to use something like
> benchmark{rx,tx} to test it ota.
>
>>
>> I've built a couple of sample flowgraphs. The first one is a BPSK
>> loopback:
>>
>>> from gnuradio import gr, digital
>>>
>>> src_data = (range(0,256))
>>>
>>> # blocks
>>> src = gr.vector_source_b( src_data )
>>> mod = digital.bpsk.bpsk_mod()
>>> demod = digital.bpsk.bpsk_demod()
>>> repacker = gr.unpacked_to_packed_bb(1, gr.GR_MSB_FIRST)
>>> dst = gr.vector_sink_b()
>>>
>>> # flow graph
>>> tb = gr.top_block()
>>> tb.connect(src, mod, demod, repacker, dst)
>>> tb.run()
>>> print dst.data()
>>>
>>
>>
>> It's output is *almost* correct:
>>
>>> (0, 0, 0, 0, 0, 0, 0, 20, 18, 128, 0, 129, 1, 130, 2, 131, 3, 132, 4,
>>> 133, 5, 134, 6, 135, 7, 136, 8, 137, 9, 138, 10, 139, 11, 140, 12, 141, 13,
>>> 142, 14, 143, 15, 144, 16, 145, 17, 146, 18, 147, 19, 148, 20, 149, 21,
>>> 150, 22, 151, 23, 152, 24, 153, 25, 154, 26, 155, 27, 156, 28, 157, 29,
>>> 158, 30, 159, 31, 160, 32, 161, 33, 162, 34, 163, 35, 164, 36, 165, 37,
>>> 166, 38, 167, 39, 168, 40, 169, 41, 170, 42, 171, 43, 172, 44, 173, 45,
>>> 174, 46, 175, 47, 176, 48, 177, 49, 178, 50, 179, 51, 180, 52, 181, 53,
>>> 182, 54, 183, 55, 184, 56, 185, 57, 186, 58, 187, 59, 188, 60, 189, 61,
>>> 190, 62, 191, 63, 192, 64, 193, 65, 194, 66, 195, 67, 196, 68, 197, 69,
>>> 198, 70, 199, 71, 200, 72, 201, 73, 202, 74, 203, 75, 204, 76, 205, 77,
>>> 206, 78, 207, 79, 208, 80, 209, 81, 210, 82, 211, 83, 212, 84, 213, 85,
>>> 214, 86, 215, 87, 216, 88, 217, 89, 218, 90, 219, 91, 220, 92, 221, 93,
>>> 222, 94, 223, 95, 224, 96, 225, 97, 226, 98, 227, 99, 228, 100, 229, 101,
>>> 230, 102, 231, 103, 232, 104, 233, 105, 234, 106, 235, 107, 236, 108, 237,
>>> 109, 238, 110, 239, 111, 240, 112, 241, 113, 242, 114, 243, 115, 244, 116,
>>> 245, 117, 246, 118, 247, 119, 248, 120, 249, 121, 250, 122, 251)
>>
>>
>> The first few bytes are 0's, which as I understand has to do with the RRC
>> filters, frequency correction, and possibly agc filter. Then it starts at
>> 128, 0 and increments by 1. I think I would expect it it to go from 0..255
>> but it looks like something else that's also incrementing by 1 is
>> interleaved in there. Looking at the output before the repacker confirms
>> that each byte appears repeated twice, but the first instance has the MSB
>> set to 1.
>>
>>
>> It turns out that this was a synchronisation/filter initialisation issue.
> The bytes are packed 1 bit off so that the MSB of each byte is the LSB of
> the previous byte. It alternates because the input data is counting by 1s.
> It just happens that for the particular set of filters in this path the
> first bit is apparently eaten and at the end an extra bit is tacked on.
>
>
>> A related question, where is the packing being done in the benchmark_rx
>> path? The generic_demod does an unpack_k_bits, but doesn't appear to pack
>> them back up. In the benchmark_rx callback it looks like the packet is
>> already full of packed bytes, but I haven't seen the unpacked_to_packed in
>> pkt.py.
>>
>>
> I think I found this in gr-digital/lib/digital_framer_sink_1.cc. There's
> some bit shifting to reassemble the payload in there.
>
>
> Just posting an update so that no one spends needless time trying to help
> me and for anyone in the future that finds this in a search.
>
> ___
> 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] Scheduler Question

[Almohanad Fayez]

I've been reading through the code in gnuradio-core/runtime for a few days
to understand the internal workings of the gnuradio scheduler.  It seems to
me that gnuradio was originally based on a synchronous dataflow (sdf) model
of computation and the single thread schedule is an SDF sequential runtime
schedule, or a periodic admissible sequential schedule (PASS), and the
thread per block schedule is a parallel SDF scheduler, or a parallel
admissible parallel schedule (PAPS).

Does this sound like an accurate description of the schedulers and
underlying gnuradio model of computation or am I reading too much into it?
thanks

-- 
Almohanad (Al) Fayez
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] RRC Polyphase Filter in generic modulator

[Almohanad Fayez]

Thanks martin for your explanation.  I modified the dbpsk_loopback.grc
example to where my input sampling frequency is 16khz and instead of
looping back i'm using a uhd sink block with a sampling rate of 256khz.
Looking at the constellation on my spectrum analyzer i'm getting a dbpsk
signal with a symbol rate of 128khz.

Since the flowgraph seems to be working i'm expecting an interpolation
factor of 16 somewhere i originally was trying to do it with a FIR filter
before sending it to the usrp but then i found out that modulation block
itself has an internal rrc filter.  Now I am trying to figure out where the
interpolation factor of 16 is occurring in the polyphase filter.

I'm confused how things are working without an explicit interpolation
factor of 16.  I'm not sure if the issue is my lack of understanding of
polyphase filters or I didn't see where the interpolation factor is
calculated internally.

Thanks
On Feb 22, 2013 2:39 AM, "Martin Braun (CEL)"  wrote:

> Almohanad,
>
> perhaps the examples in gr-digital/examples/demod are more suitable to
> understand the internals.
>
> A couple of notes:
>
>
> On Thu, Feb 21, 2013 at 08:58:42PM -0500, Almohanad Fayez wrote:
> > I've been trying to understand what's happening under the hood with the
> > polyphase filter bank in the generic_mod_demod.py.
> >
> >
> > Here's what I think is happening, since nfilt=32 which is also used the
> > sampling rate of the firdes.root_raised_cosine filter means that the
> highest
> > rate the polyphase filter will see is an interpolation factor of 32 from
> the
> > basic inputted signal sampling frequency?
>
> PFB filter taps operate on what you could think of as 'fractional'
> time, i.e. the sampling time is 1/32th (or whatever) of the original
> sampling time. If you have a cutoff frequency in your low pass, that
> must be taken care of in the filter taps (i.e. reduced by factor 32).
> If you're specifying absolute frequencies, just increase the sampling
> frequency (hm, I'm not sure this is really clear...).
>
> > the default case is =2 ... does this mean that the polyphase filter is
> > interpolating by a factor of 2?
>
> When going from symbols to samples, you always have to interpolate.
> Usual values are 2 (as used here) or 4.
>
> > If I am inputting data at a sampling rate of 16kHz and I'm trying to
> > interpolate them to 256kHz before sending them to the user how is the
> 256kHz
> > and the desired interpolation factor of 16 taken into account in the RRC
> filter
> > in the generic modulator block.
>
> I don't understand this Q. The answer is probably, you'll need an extra
> interpolation block, depending on how your FG looks like.
>
> > I've read the gnuradio pfb page but I think I'm missing something
> important
> > here.
>
> Just to be clear, you do know what an FIR does and how filter taps are
> defined? Or is this the information you're lacking?
>
> MB
>
> --
> Karlsruhe Institute of Technology (KIT)
> Communications Engineering Lab (CEL)
>
> Dipl.-Ing. Martin Braun
> Research Associate
>
> Kaiserstraße 12
> Building 05.01
> 76131 Karlsruhe
>
> Phone: +49 721 608-43790
> Fax: +49 721 608-46071
> www.cel.kit.edu
>
> KIT -- University of the State of Baden-Württemberg and
> National Laboratory of the Helmholtz Association
>
> ___
> 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] RRC Polyphase Filter in generic modulator

[Almohanad Fayez]

I've been trying to understand what's happening under the hood with the
polyphase filter bank in the generic_mod_demod.py.

Here's what I think is happening, since nfilt=32 which is also used the
sampling rate of the firdes.root_raised_cosine filter means that the
highest rate the polyphase filter will see is an interpolation factor of 32
from the basic inputted signal sampling frequency?

while pfb.arb_resampler_ccf has a sampling rate of samples_per_symbol which
in the default case is =2 ... does this mean that the polyphase filter is
interpolating by a factor of 2?

If I am inputting data at a sampling rate of 16kHz and I'm trying to
interpolate them to 256kHz before sending them to the user how is the
256kHz and the desired interpolation factor of 16 taken into account in the
RRC filter in the generic modulator block.

I've read the gnuradio pfb page but I think I'm missing something important
here.


Thanks
-- 
Almohanad (Al) Fayez
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] cross compiling (Swig issue?)

[Almohanad Fayez]

Chris, I'm a little confused by "I used SWIG 2.0.4 on the host"  I haven't
used OpenWRT but the assumption is that you have a cross compiled swig on
your host which you're linking against and have installed on your embedded
target.  It sounds like either some library is not installed properly but
again it can be an environmental variable issue.

Are you making packages via openwrt? Filesystem? Can you provide some more
details?  The easy but lng way to get gnuradio working on embedded
platforms might be a native compilation  Philip Balister might have
more insight ... he always does :)
On Jun 25, 2012 10:21 AM, "cjpatton"  wrote:

>
> Hello all,
>
> I've tried to build GNU Radio 3.6.0 for an embedded system running OpenWRT.
> I cross compiled with OpenWRT's toolchain, but used Swig 2.0.4 on the host
> system. When I try to run a GNU Radio program that requires Python, I get
> the following error:
>
> root@OpenWrt:~# usrp_flex
> Traceback (most recent call last):
>  File "/usr/bin/usrp_flex", line 24, in 
>from gnuradio import gr, gru, uhd, optfir, eng_notation, pager
>  File "/usr/lib/python2.7/dist-packages/gnuradio/gr/__init__.py", line 43,
> in 
>from gnuradio_core import *
>  File "/usr/lib/python2.7/dist-packages/gnuradio/gr/gnuradio_core.py", line
> 23, in 
>from gnuradio_core_runtime import *
>  File
> "/usr/lib/python2.7/dist-packages/gnuradio/gr/gnuradio_core_runtime.py",
> line 26, in 
>_gnuradio_core_runtime = swig_import_helper()
>  File
> "/usr/lib/python2.7/dist-packages/gnuradio/gr/gnuradio_core_runtime.py",
> line 22, in swig_import_helper
>_mod = imp.load_module('_gnuradio_core_runtime', fp, pathname,
> description)
> ImportError: File not found
>
> My first hunch is that I am missing environment variables, but I'm not
> really sure. It could also be a problem with Swig, which is why I'm posting
> this; I don't know much about this program. Any help would be greatly
> appreciated, and thanks in advance for any help!
>
> Regards,
> Chris
> --
> View this message in context:
> http://old.nabble.com/cross-compiling-%28Swig-issue-%29-tp34068092p34068092.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

Re: [Discuss-gnuradio] [USRP-users] what is the largest data transfer rate between fpga and overo in e100

[Almohanad Fayez]

I don't believe there's a document for this it's more of an exercise left
for the motivated user.
On May 30, 2012 6:27 AM, "Page Jack"  wrote:

> Hi Almohanad ,
> thanks for this information, can you provide more detail or is there any
> doc?
>
> On 5/30/12, Almohanad Fayez  wrote:
> > If memory serves correctly the n200 or the usrp 2 has an fpga expansion
> > interface to some xilinx development platform which you might be able to
> > use to create a custom solution to serve your needs.
> >
> > Al
> > On May 29, 2012 6:17 PM, "Page Jack"  wrote:
> >
> >> I don't want to using a ethernet wire to connect N series to an ARM
> >> board.
> >> anyone have tried
> >> build N series with ARM or DSP in one board which means the ethernet
> line
> >> between N and
> >> the processor is on PCB.
> >>
> >> On Wed, May 30, 2012 at 6:24 AM, Philip Balister
> >> wrote:
> >>
> >>> On 05/25/2012 09:18 PM, Page Jack wrote:
> >>> > Hi Philip,
> >>> > How does the conclusion be made that ARM can not swallow the current
> >>> > max data transfer rate? I need to build a project that need to
> process
> >>> > 60MB/s data, so any way to achieve my goal. Use a more powerful CPU
> or
> >>> > use dsp on the omap?
> >>>
> >>> 60 MB/s is far more data than the OMAP3 can transfer from the FPGA. We
> >>> have worked hard on configuring the GPMC interface and this figure is
> >>> basically an order of magnitude more then the hardware will support.
> >>>
> >>> You need to look at the N series with Gig-E, or do the high rate
> >>> processing in the FPGA.
> >>>
> >>> Philip
> >>>
> >>>
> >>> >
> >>> > On 5/25/12, Philip Balister  wrote:
> >>> >> On 05/24/2012 09:46 PM, Page Jack wrote:
> >>> >>> Thanks Ben,
> >>> >>> does e100 use EMIF to transfer sample data between FPGA and ARM? If
> >>> >>> so
> >>> >>> the
> >>> >>> data rate should be able to improved.
> >>> >>> Anyone have tried to improve the data rate?
> >>> >>
> >>> >> EMIF is basically identical to GPMC. The interface uses DMA to move
> >>> data
> >>> >> in 2K chunks between the FPGA and memory. This is the largest
> >>> >> transfer
> >>> >> possible due to how we connected the address and data lines
> >>> >>
> >>> >> My impression of the current limiting factor is interrupt response
> >>> time.
> >>> >> There is probably some room for small improvements, but as Ben
> notes,
> >>> we
> >>> >> are already collecting data faster than the ARM can swallow it.
> >>> >>
> >>> >> Philip
> >>> >>
> >>> >>>
> >>> >>> Regards
> >>> >>>
> >>> >>> On Thu, May 24, 2012 at 9:01 AM, Ben Hilburn <
> ben.hilb...@ettus.com>
> >>> >>> wrote:
> >>> >>>
> >>> >>>> The CPU sets up the initial DMA parameters, but from then on, it's
> >>> pure
> >>> >>>> DMA.  No CPU is required.
> >>> >>>>
> >>> >>>> Cheers,
> >>> >>>> Ben
> >>> >>>> 
> >>> >>>> Ben Hilburn <http://goo.gl/5DdZ3> @ Ettus Research,
> >>> >>>> LLC<http://www.ettus.com/>
> >>> >>>>
> >>> >>>>
> >>> >>>>
> >>> >>>> On Wed, May 23, 2012 at 5:55 PM, Page Jack <
> jack.page...@gmail.com>
> >>> >>>> wrote:
> >>> >>>>
> >>> >>>>> Thanks, does the ARM memory bus use DMA or it eat cpu?
> >>> >>>>>
> >>> >>>>>
> >>> >>>>> On Thu, May 24, 2012 at 5:06 AM, Ben Hilburn
> >>> >>>>> wrote:
> >>> >>>>>
> >>> >>>>>> Page -
> >>> >>>>>>
> >>> >>>>>> The memory bus to the ARM provides 40 MBytes / second.  This is
> >>> used
> >

Re: [Discuss-gnuradio] [USRP-users] what is the largest data transfer rate between fpga and overo in e100

[Almohanad Fayez]

If memory serves correctly the n200 or the usrp 2 has an fpga expansion
interface to some xilinx development platform which you might be able to
use to create a custom solution to serve your needs.

Al
On May 29, 2012 6:17 PM, "Page Jack"  wrote:

> I don't want to using a ethernet wire to connect N series to an ARM board.
> anyone have tried
> build N series with ARM or DSP in one board which means the ethernet line
> between N and
> the processor is on PCB.
>
> On Wed, May 30, 2012 at 6:24 AM, Philip Balister wrote:
>
>> On 05/25/2012 09:18 PM, Page Jack wrote:
>> > Hi Philip,
>> > How does the conclusion be made that ARM can not swallow the current
>> > max data transfer rate? I need to build a project that need to process
>> > 60MB/s data, so any way to achieve my goal. Use a more powerful CPU or
>> > use dsp on the omap?
>>
>> 60 MB/s is far more data than the OMAP3 can transfer from the FPGA. We
>> have worked hard on configuring the GPMC interface and this figure is
>> basically an order of magnitude more then the hardware will support.
>>
>> You need to look at the N series with Gig-E, or do the high rate
>> processing in the FPGA.
>>
>> Philip
>>
>>
>> >
>> > On 5/25/12, Philip Balister  wrote:
>> >> On 05/24/2012 09:46 PM, Page Jack wrote:
>> >>> Thanks Ben,
>> >>> does e100 use EMIF to transfer sample data between FPGA and ARM? If so
>> >>> the
>> >>> data rate should be able to improved.
>> >>> Anyone have tried to improve the data rate?
>> >>
>> >> EMIF is basically identical to GPMC. The interface uses DMA to move
>> data
>> >> in 2K chunks between the FPGA and memory. This is the largest transfer
>> >> possible due to how we connected the address and data lines
>> >>
>> >> My impression of the current limiting factor is interrupt response
>> time.
>> >> There is probably some room for small improvements, but as Ben notes,
>> we
>> >> are already collecting data faster than the ARM can swallow it.
>> >>
>> >> Philip
>> >>
>> >>>
>> >>> Regards
>> >>>
>> >>> On Thu, May 24, 2012 at 9:01 AM, Ben Hilburn 
>> >>> wrote:
>> >>>
>>  The CPU sets up the initial DMA parameters, but from then on, it's
>> pure
>>  DMA.  No CPU is required.
>> 
>>  Cheers,
>>  Ben
>>  
>>  Ben Hilburn  @ Ettus Research,
>>  LLC
>> 
>> 
>> 
>>  On Wed, May 23, 2012 at 5:55 PM, Page Jack 
>>  wrote:
>> 
>> > Thanks, does the ARM memory bus use DMA or it eat cpu?
>> >
>> >
>> > On Thu, May 24, 2012 at 5:06 AM, Ben Hilburn
>> > wrote:
>> >
>> >> Page -
>> >>
>> >> The memory bus to the ARM provides 40 MBytes / second.  This is
>> used
>> >> for
>> >> streaming samples, as controlled via software.  Currently, UHD
>> supports
>> >> 16
>> >> bit and 8 bit samples for TX & RX.  The GPMC can only going to
>> talk to
>> >> one
>> >> slave at a time; the possible slaves are TX, RX, and ethernet.  So
>> you
>> >> can
>> >> only be sending TX samples, receiving RX samples, or communicating
>> via
>> >> ethernet.
>> >>
>> >> Thus, doing the math with the numbers above, you can stream:
>> >> 16 bit I, 16 bit Q -- Total: 32-bit samples -- @ 10 MSps
>> >> 8 bit I, 8 bit Q -- Total: 16-bit samples -- @ 20 MSps
>> >>
>> >> What you choose to do with this data is obviously up to you. It is
>> >> very
>> >> easy to try to do more processing than the ARM can handle, in which
>> >> case
>> >> samples will start getting thrown out by UHD.  Thus, you can
>> typically
>> >> process between 4 and 8 MHz of baseband bandwidth, depending on
>> your
>> >> application.  If you are willing to dig deep into the code to make
>> NEON
>> >> and
>> >> C64 optimizations, you can improve the performance dramatically.
>> >>
>> >> Cheers,
>> >> Ben
>> >> 
>> >> Ben Hilburn  @ Ettus Research,
>> >> LLC
>> >>
>> >>
>> >>
>> >> On Tue, May 22, 2012 at 7:47 PM, Page Jack
>> >> wrote:
>> >>
>> >>> Hi,
>> >>> I want to know the overo model used in e100 and the largest data
>> >>> transfer rate between fpga  and overo in e100.
>> >>>
>> >>> Regards!
>> >>>
>> >>> ___
>> >>> USRP-users mailing list
>> >>> usrp-us...@lists.ettus.com
>> >>>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> >>>
>> >>>
>> >>
>> >
>> 
>> >>>
>> >>>
>> >>>
>> >>> ___
>> >>> USRP-users mailing list
>> >>> usrp-us...@lists.ettus.com
>> >>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> >>
>> >
>> > ___
>> > USRP-users mailing list
>> > usrp-us...@lists.ettus.com
>> > http://lists.ettus.com/m

Re: [Discuss-gnuradio] "GNU Radio is crap" and GSoc

[Almohanad Fayez]

I also agree that a big issue with gnuradio is that it tries to take over all 
the computing resources in an application but in my opinion that this is not an 
inherent issue with the gnuradio scheduler not wanting to play with other 
applications.  Some people complain that gnuradio doesn't provide an API with 
functions that can be called to a process data in their external applications, 
I haven't tried this per se, but isn't that the purpose behind gnuradio 
supports running c++-only apps?  But people need to be careful what they ask 
for, if they get only an API to call basic gnuradio functionality to process 
data they want to be processed the overall performance might not be acceptable 
because they are ultimately giving up the scheduler.  Processing is done in 
gnuradio the way they are, at least in my opinion, to address the issue of 
running a Synchronous Dataflow (SDF) graphs which is exactly what you want for 
signal processing, and an integral part of running SDF graphs is running a 
suitable scheduler.

What gnuradio lacks is coherent links to the scheduler in my experience it is 
fairly difficult to step through the code with gdb to figure out what the 
scheduler is doing, if users are able to have some control over the scheduler 
or replace it entirely for custom applications where gnuradio needs to work in 
cohesion with other apps then gnuradio can run as part of a larger system 
versus being the only system running.  While this might be outside the scope of 
a GSoC project but it's a necessity for gnuradio to progress beyond its current 
state.

Almohanad (Al) Fayez




-Original Message-
From: Andrew Davis 
To: Jens Elsner ; discuss-gnuradio 
Sent: Thu, Feb 16, 2012 9:03 am
Subject: Re: [Discuss-gnuradio] "GNU Radio is crap" and GSoc


>I don't agree. We'll hopefully settle the matter some day. :-)
Me too, DREAM is an amazing SDR program that could benefit from
NURadio and show off GNURadio as-well. But this idea has been batted
round before and never really develops, possibly due to the way
NURadio is currently setup. When I get some free time i'll continue
etting some of the python examples ported to C++, so that potential
evelopers who prefer C over python can see how things can be done
rom C world. I think this will get people who find GNURadio to start
orting other C based programs to the GNURadio framework.
On Thu, Feb 16, 2012 at 8:52 AM, Jens Elsner  wrote:
 Andrew,

 Am 15.02.2012 19:41, schrieb Andrew Davis:

> Well some major GNUradio program would drive up sales of USRP's :)
>
> Back on topic, IMHO Gnuradio's problem with large apps stems from it
> trying to be the source to sink and everything in between of a radio.


> Lets take DREAM for example, they do transfer functions and digital
> AGC and the likes that GNUradio by design should not do.


 If you could elaborate on this point - why should GNU Radio not implement
 channel equalization (I assume that's what you mean?) or digital AGC?


> If you want
> to re-write DREAM with GNUradio you will end up writing about +200
> blocks, not much fun.


 Since I suggested this particular project, I obviously cannot agree. :-)

 Pulling the code base into GNU Radio might be a nice addition to
 the available receivers and it can be useful for all amateur radio
 operators world wide.

 Plus DRM is broadcasting so we don't need to worry about timing issues,
 a real drawback of GNU Radio (and high level SDR in general).

 How fine the signal processing chain needs to be chopped up is a
 matter of taste and performance, I believe.


> What people want is simple input to there
> program and a simple output API, not there entire program. They don't
> what to figure out how to write a GNURadio block or know anything
> about the complexities of GNURadio. They want to say "get me a signal
> at 100MHz, filter and interpolate to 1ksp with these cutoff
> frequencies then send me the data and let me do the rest", no need to
> know anything about GNURadio, what other API makes you learn as much
> about it?


 I am not sure I understand your point here. That is not GNU Radio, I
 see GNU Radio as a scheduler with a big collection of signal processing
 blocks attached.

 [...]


> Back to DREAM,
> a lot of the filters, audio input/output, signal conditioning, etc
> could be in GNURadio, but a lot of the middle section cannot. GNURadio


 Then it would be nice to find out what exactly is lacking to add this
 to GNU Radio.


> can not be the whole program, just helper functions in big programs
> like this. Only about %20 of DREAM could be replaced with GNURadio API
> calls, but instead you will have to rewrite it %100 as GNURadio blocks
> with the current block to block only mentality 


 I don't agree. We'll hopefully settle the matter some day. :-)

 Jens



 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Scheduler slides from gnuradio conference

[Almohanad Fayez]

I was trying to download the slides about the scheduler from the gnuradio 
conference and for some reason they are not available with the other slides 
 are they posted or available somewhere else online?  thanks


Almohanad (Al) Fayez
alfa...@aol.com

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Help please!

[Almohanad Fayez]

 

Javier, the RFX2200 daughterboard works in the following frequency range 
2.0–2.4 GHz you're trying to use it outside the supported frequencies (2.45GHz 
and 93.3 MHz) you should either work with the supported frequencies or buy a 
different daughterboard to work with those frequencies
 

Almohanad Fayez
alfa...@aol.com

 

 

-Original Message-
From: Javier Suarez 
To: discuss-gnuradio 
Sent: Fri, Feb 3, 2012 11:50 am
Subject: [Discuss-gnuradio] Help please!


Good morning,
I am working with Gnuradio +UHD version 3.5.1, the daughter boardas are RFX 
2200 and frequency: 2400 - 25000 MHz.I want to make a simple spectrum analizer, 
I tried to do it by myself but I always had a mistake. Then I started to try 
with an example who came with it  which is uhd_ fft.grc but I had the same 
mistake too:


linux; GNU C++ version 4.4.3; Boost_104000; UHD_003.004.000-5b06adb

-- Opening a USRP1 device...
-- Using FPGA clock rate of 64.00MHz...

UHD Warning:
The hardware does not support the requested RX frequency:
Target frequency: 2450.00 MHz
Actual frequency: 2386.00 MHz
thread[thread-per-block[0]: ]: caught 
unrecognized exception


On the other hand,
 I tried to test the wbfm receiver, other example that came with the software, 
tunning at 93.3 MHz but this mistakes appears:

UHD Warning:
The hardware does not support the requested RX frequency:
Target frequency: 93.30 MHz
Actual frequency: 2013.30 MHz

I was expecting to see something in the spectrum analyzer at 93.3 and listening 
something.


I don't know what to do, I've tried a lot but I don't know why it says that the 
hardware doesnt support the frequency

Thanks a lot in advance

ATT
Javier M.

 
___
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

Re: [Discuss-gnuradio] Try to improve E100's performance at high sample rate

[Almohanad Fayez]

I haven't used VOLK with the OMAP processor but from my experience with the 
E100 every multiplication and/or division in your flowgraph counts ... When I 
was working on my C64x+ DSP based FM receiver on the E100 I was moving 
individual blocks 1-by-1 from the GPP to the DSP and almost every 
multiplication/division on the GPP caused a buffer overflow my impression at 
least is if you're going for a pure GPP implementation you need to make used of 
NEOS vector operations and if you're using a DSP based solution you'll need to 
find a way to speed up the GPP/DSP buffers, which is something I'm hoping to 
have more time to look into.



 
Almohanad Fayez
alfa...@aol.com

 

 

-Original Message-
From: Evan Merewether 
To: discuss-gnuradio 
Sent: Tue, Jan 24, 2012 1:22 pm
Subject: Re: [Discuss-gnuradio] Try to improve E100's performance at high 
sample rate


Has anybody looked at using the CORDIC approximation for atan2?  Depending

on the required accuracy, this may dramatically improve performance in your

C code.  Ultimately, you can implement the CORDIC functions in the FPGA

(quasi math-coprocessor style) which would then give you the fastest

possible computation speed.



Evan



-Original Message-

From: discuss-gnuradio-bounces+evan=syndetix@gnu.org

[mailto:discuss-gnuradio-bounces+evan=syndetix@gnu.org] On Behalf Of

ziyang

Sent: Tuesday, January 24, 2012 10:56 AM

To: Nick Foster

Cc: discuss-gnuradio@gnu.org

Subject: Re: [Discuss-gnuradio] Try to improve E100's performance at high

sample rate



On 01/19/2012 07:13 PM, Nick Foster wrote:

> Optimizing an algorithm is a hard and sometimes counterintuitive 

> process. You might benchmark the following:

>

> - Gnuradio's atan2 WITHOUT any Volk multiplications (just comment out 

> the volk mults in your block)

> - The Volk multiplications WITHOUT Gnuradio's atan2 (just comment out 

> the atan2 in your block)

>

> This will let you determine where the bottleneck is. In addition, try 

> running over a MUCH larger dataset. The clock resolution at <1ms is 

> not very good and the scheduler will have a correspondingly larger 

> effect at smaller timescales.

>

> I think you'll find the atan2 part takes vastly longer than the 

> multiplications do, and that will be where you have to look for 

> performance improvements.

>

> --n

>





Hi Nick,



I have been doing some tests about the demodulation module. As you said, 

the atan2 part takes much longer than the multiplication. So in order to 

maximize the performance improvement that volk could bring to the 

processing, I took a division and a multiplication out of atan2, and use 

volk-ified divider and multiplier instead. Then I run tests using a much 

larger dataset.



But from the test results, I did not observe a performance improvement. 

In fact, the average processing time even increase a little bit. So I 

was wondering if what I did was not a good way to improve the performance?



Another issue is that when I ran Cmake to build Gnuradio on E100, it 

reported this:

-- Available arches: generic;neon

-- Available machines: generic;neon

-- Did not find liborc and orcc, disabling orc support...



But from the "opkg list-installed | grep orc" check, both orc and liborc 

are installed. Could this lack of orc support be part of the reason why 

my implementation did not have a performance improvement?



I will appreciate it if you could give me a hand on this. Thanks.





Best Regards,



Terry











___

Discuss-gnuradio mailing list

Discuss-gnuradio@gnu.org

https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

-

No virus found in this message.

Checked by AVG - www.avg.com

Version: 2012.0.1901 / Virus Database: 2109/4763 - Release Date: 01/24/12





___

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

Re: [Discuss-gnuradio] making gnuradio blocks entirely in python

[Almohanad Fayez]

The "in" buffer should start at in[0] the history comes into play at allowing 
enough valid indices to perform the filtering operation over the entire buffer 
which allows N valid output data versus N-nTAPS.  When I looked at filtering in 
gnuradio the way I thought about it as and at the end I've included some ASCII 
art to demonstrate it, from the illustration you can see how the history comes 
into play.  I'm no DSP engineer but this seems to work for me someone can feel 
free to correct me if I'm wrong.


< adapted from gr_fir_fff_generic.cc>


for(i=0; i
To: Discuss-gnuradio 
Sent: Sun, Sep 25, 2011 6:59 pm
Subject: [Discuss-gnuradio] making gnuradio blocks entirely in python


So there is a useful feature I think gnuradio is missing, and thats the
ability to rapidly prototype signal processing in python. It would be
great if a python block would have access to all the facilities
available to a block written in a c++ environment.

So I put together pyblock (not to be confused with those other project
by the same name). Its a stand-alone build that links against gnuradio.
https://github.com/guruofquality/pyblock

Theres a few demos: an adder, using tags, interp and decim blocks.
https://github.com/guruofquality/pyblock/tree/master/examples

The interesting thing is that the work functions just call into numpy
routines, so there is a chance that the implementations can be
reasonably fast.

I would like to be able to support history so i can implement a filter
using numpy but I am a little lacking in the basic understanding so fill
me in if you know. Suppose I have this work function:

int work(int noutput_items, gr_vector_const_void_star
&input_items,gr_vector_void_star &output_items){
const float *in = reinterpret_cast(input_items[0]);

I am assuming history is on the input buffer.
Is the vector "in" ninput_items + history() items long? Where
ninput_items = noutput_items*/some_factor.
Whats the first index of the first item? Is in[0] or in[0-history()]?

-Josh

___
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

Re: [Discuss-gnuradio] Converting complex-short to complex-float with UHD

[Almohanad Fayez]

Thanks Josh, I'll probably end up doing that, but I'm assuming that there is no 
way to do a quick dirty test from COMPLEX_INT16 to complex-float type and I 
will need to make a new block that does that right? 


and obviously combine those functions to make things faster and prettier

al fayez

 

 


 

 

-Original Message-
From: Josh Blum 
To: Almohanad Fayez 
Cc: discuss-gnuradio 
Sent: Mon, Sep 12, 2011 1:46 pm
Subject: Re: [Discuss-gnuradio] Converting complex-short to complex-float with 
UHD






On 09/12/2011 10:28 AM, Almohanad Fayez wrote:

> 

> I want to use COMPLEX_INT16 in hopes of generating non-normalized

> fixed point data using UHD.  I ultimately want to send this data over

> to the DSP on the E100, if I receive the data as COMPLEX_FLOAT32 then

> UHD is performing

> 

> fixed-point -> floating point  and I will be performing

> floating-point -> fixed-point -> floating-point feeding into the

> FPGA.  Ultimately I want

> 

> FPGA ->fixed-point -> DSP -> fixed-point -> FPGA

> 

> instead of

> 

> FPGA ->fixed-point -> floating-point -> fixed_point -> DSP ->

> fixed-point -> floating-point -> fixed-point -> FPGA

> 



Ah, makes sense.



> however in my flowgraph I want to be able to use

> gr.probe_avg_mag_sqrd() and a scalar multiples before feeding into

> the DSP and it fails when I use  COMPLEX_INT16 because of data type

> confusion

> 



It may be better to combine this scalar multiply/conversion with the

copy into DSP memory. You can save a step writing the output of the

conversion directly to DSP memory.



-Josh


 
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Converting complex-short to complex-float with UHD

[Almohanad Fayez]

 I want to use COMPLEX_INT16 in hopes of generating non-normalized fixed point 
data using UHD.  I ultimately want to send this data over to the DSP on the 
E100, if I receive the data as COMPLEX_FLOAT32 then UHD is performing 

fixed-point -> floating point  and I will be performing floating-point -> 
fixed-point -> floating-point feeding into the FPGA.  Ultimately I want

FPGA ->fixed-point -> DSP -> fixed-point -> FPGA

instead of 

FPGA ->fixed-point -> floating-point -> fixed_point -> DSP -> fixed-point -> 
floating-point -> fixed-point -> FPGA

however in my flowgraph I want to be able to use gr.probe_avg_mag_sqrd() and a 
scalar multiples before feeding into the DSP and it fails when I use  
COMPLEX_INT16 because of data type confusion

al fayez

 


 

 

-Original Message-
From: Josh Blum 
To: discuss-gnuradio 
Sent: Mon, Sep 12, 2011 1:18 pm
Subject: Re: [Discuss-gnuradio] Converting complex-short to complex-float with 
UHD






On 09/12/2011 10:00 AM, Almohanad Fayez wrote:

> 

> I can't seem to find a direct way of typcasting COMPLEX_INT16 using

> gr-uhd as complex_float.  It seems that gnuradio assumes that a

> complex type is composed of floats by default which causes issues

> when I'm using gr-uhd, is there a direct way to do complex_short to

> complex_float conversion or should I just make a custom block for

> that?  thanks.

> 



The output signature for COMPLEX_INT16 is a vector of shorts length 2.

You can covert this to complex float with a vector_to_stream block, and

then a ishort_to_complex block.



BTW, if you want complex floats, it makes way more sense to just use

COMPLEX_FLOAT32. The real use of COMPLEX_INT16 is if you have a block

that produces or consumes complex shorts. Otherwise its just extra overhead.



-josh





___

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] Converting complex-short to complex-float with UHD

[Almohanad Fayez]

I can't seem to find a direct way of typcasting COMPLEX_INT16 using gr-uhd as 
complex_float.  It seems that gnuradio assumes that a complex type is composed 
of floats by default which causes issues when I'm using gr-uhd, is there a 
direct way to do complex_short to complex_float conversion or should I just 
make a custom block for that?  thanks.

al fayez

 


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [USRP-users] USRP-E100 update (new kernel and rootfs)

[Almohanad Fayez]

 If you update the kernel uImage in your FAT partition, the filesystem, 
recompile UHD from GIT, and update your FPGA images things should work fine ... 
at least it worked for me!

 


 al fayez


 

-Original Message-
From: Radio Man 
To: Philip Balister 
Cc: usrp-users ; GNURadio Discussion List 

Sent: Fri, Aug 5, 2011 5:26 pm
Subject: Re: [USRP-users] USRP-E100 update (new kernel and rootfs)


Phil,
What may be the reason that after updating FAT and uploading rootfs with new 
files It blows when python is interpreting 
from gnuradio import uhd

I need to upload new UHD from GIT and compile it?
WD


 
___
USRP-users mailing list
usrp-us...@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

 
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr-dsp Library Block Parameters

[Almohanad Fayez]

 Chris, I FINALLY got around looking at and fixing the problem ... I pushed 
updates to the easyCom-gpp and easyCom-dsp repos and updated the gpp prebaked 
packages there was a memory alignment issue that i didn't backup properly so I 
didn't push to the repos ... moral of the story regular backups are a good 
thing :)  

Try to keep your filter input and taps as multiples of 4, I added extra data 
points to the python file you sent me to do that.  The DSP will always load 4 
data points at a time which might not be an issue if the buffer has zeros in 
the latter locations but if you have left over data points from a previous 
filter operation it can throw your result off ... I need to add code that 
automatically pads unaligned input by zeros to address this but I won't get 
around to it for a while.

As a piece of advise if you start developing code for the DSP, memory alignment 
can be an absolute nightmare so I really need to add API functions to handle it 
so developers won't have to face them with each newly developed function.

Tell me if this update works for you.

al

 


 

 

-Original Message-
From: Christopher Dean 
To: Almohanad Fayez 
Cc: discuss-gnuradio 
Sent: Thu, Jul 14, 2011 12:53 pm
Subject: Re: [Discuss-gnuradio] gr-dsp Library Block Parameters


I compiled the DSP code, as of Monday.  How long ago did you
find/fix the issue?


On 7/14/2011 12:50 PM, Almohanad Fayez wrote:
Did yourecompile the DSP code or did you download the the precompiled   
 binary?  I think there was an issue that I fixed in the DSP code
but didn't update the binary.

al


-Original Message-
  From: Christopher Dean 
  To: Almohanad Fayez 
  Cc: discuss-gnuradio 
  Sent: Thu, Jul 14, 2011 11:12 am
  Subject: Re: [Discuss-gnuradio] gr-dsp Library Block  
Parameters
  
  
HiAl,

That really clears things up conceptually.  Thanks for the  
  insight.

Given that, I went back and modified the dsp test case to   
 use a scaling factor of 15, normalized input, and normalized
output, so the block invocation was "dsp.fir_ccf (src_coeff,15, 1, 
0, 0, 0, 0)".  Running the test provides:

  -0.0102 - 0.0102i
  -0.0104 - 0.0103i
  -0.0105 - 0.0105i
  -0.0106 - 0.0106i
  -0.0107 + 0.0010i
   0.0111 + 0.0031i
   0.0334 + 0.0061i
   0.0671 + 0.0102i
   0.1122 + 0.0154i
   
However, this differs from the output of the
gr.fir_filter_ccf block and the result of direct computationin 
MATLAB:

   0.0010 + 0.0111i
   0.0030 + 0.0334i
   0.0061 + 0.0671i
   0.0102 + 0.1122i
   0.0154 + 0.1689i
   0.0205 + 0.2255i
   0.0257 + 0.2822i
   0.0308 + 0.3388i
   0.0360 + 0.3954i

I've checked the magnitude and phase of each of these
results, and it doesn't look like they're a simple rotationor 
multiple of each other.

I thought that it might just not work for decimal
sources/coefficients, so I adjusted the tests so that src =
(1,1,1,1,1,1,1,1,1) and src_coeff = (1,1,1,1,1).

Since we no longer needed to scale it before or after, our  
  block invocation is "dsp.fir_ccf (src_coeff, 15, 1, 1, 1, 0,0)".  
This gives the output:

   1.0e+04 *

   3.2748 + 3.2751i
   3.2762 + 3.2752i
   3.2762 + 3.2767i
   3.2763 - 3.2768i
  -3.2768 - 0.0001i
0 - 0.0002i
0 - 0.0003i
0 - 0.0004i
0 - 0.0005i
0  
0  
0  
0  
0  
   2.8678 - 3.2752i
  -3.2757 - 3.2751i
  -3.2757 + 0.0001i
   0.0005 - 3.2768i
  -3.2768 
 
The output from the gr.fir_filter_ccf test is the first nine
elements of the MATLAB output:  

 1
 2
 3
 4
 5
 5
 5
 5
 5
 
Finally, I thought that the issue might be that I'm not
normalizing my source coefficients.  So, I normalized themin 
MATLAB, yielding src_coeff = (0.4472, 0.447

Re: [Discuss-gnuradio] gr-dsp Library Block Parameters

[Almohanad Fayez]

 that was a while back that I fixed it, I'm currently in the process of 
verifying that all of the code I have on github is the same code that is on my 
computers.  I'm almost at the point where I'll be validating the DSP code ... 
I'll use your test case test file and step through the code with a JTAG to 
figure what's going on.

al

 


 

 

-Original Message-
From: Christopher Dean 
To: Almohanad Fayez 
Cc: discuss-gnuradio 
Sent: Thu, Jul 14, 2011 12:53 pm
Subject: Re: [Discuss-gnuradio] gr-dsp Library Block Parameters


I compiled the DSP code, as of Monday.  How long ago did you
find/fix the issue?


    On 7/14/2011 12:50 PM, Almohanad Fayez wrote:
Did yourecompile the DSP code or did you download the the precompiled   
 binary?  I think there was an issue that I fixed in the DSP code
but didn't update the binary.

al


-Original Message-
  From: Christopher Dean 
  To: Almohanad Fayez 
  Cc: discuss-gnuradio 
  Sent: Thu, Jul 14, 2011 11:12 am
  Subject: Re: [Discuss-gnuradio] gr-dsp Library Block  
Parameters
  
  
HiAl,

That really clears things up conceptually.  Thanks for the  
  insight.

Given that, I went back and modified the dsp test case to   
 use a scaling factor of 15, normalized input, and normalized
output, so the block invocation was "dsp.fir_ccf (src_coeff,15, 1, 
0, 0, 0, 0)".  Running the test provides:

  -0.0102 - 0.0102i
  -0.0104 - 0.0103i
  -0.0105 - 0.0105i
  -0.0106 - 0.0106i
  -0.0107 + 0.0010i
   0.0111 + 0.0031i
   0.0334 + 0.0061i
   0.0671 + 0.0102i
   0.1122 + 0.0154i
   
However, this differs from the output of the
gr.fir_filter_ccf block and the result of direct computationin 
MATLAB:

   0.0010 + 0.0111i
   0.0030 + 0.0334i
   0.0061 + 0.0671i
   0.0102 + 0.1122i
   0.0154 + 0.1689i
   0.0205 + 0.2255i
   0.0257 + 0.2822i
   0.0308 + 0.3388i
   0.0360 + 0.3954i

I've checked the magnitude and phase of each of these
results, and it doesn't look like they're a simple rotationor 
multiple of each other.

I thought that it might just not work for decimal
sources/coefficients, so I adjusted the tests so that src =
(1,1,1,1,1,1,1,1,1) and src_coeff = (1,1,1,1,1).

Since we no longer needed to scale it before or after, our  
  block invocation is "dsp.fir_ccf (src_coeff, 15, 1, 1, 1, 0,0)".  
This gives the output:

   1.0e+04 *

   3.2748 + 3.2751i
   3.2762 + 3.2752i
   3.2762 + 3.2767i
   3.2763 - 3.2768i
  -3.2768 - 0.0001i
0 - 0.0002i
0 - 0.0003i
0 - 0.0004i
0 - 0.0005i
0  
0  
0  
0  
0  
   2.8678 - 3.2752i
  -3.2757 - 3.2751i
  -3.2757 + 0.0001i
   0.0005 - 3.2768i
  -3.2768 
 
The output from the gr.fir_filter_ccf test is the first nine
elements of the MATLAB output:  

 1
 2
 3
 4
 5
 5
 5
 5
 5
 
Finally, I thought that the issue might be that I'm not
normalizing my source coefficients.  So, I normalized themin 
MATLAB, yielding src_coeff = (0.4472, 0.4472, 0.4472,0.4472, 
0.4472), which provided the output:

   1.0e+03 *

   6.5440 + 6.5450i
   6.5500 + 6.5460i
   6.5500 + 6.5520i
   6.5510 + 6.5530i
   6.5530 - 0.0010i
0 - 0.0010i
0 - 0.0020i
0 - 0.0020i
0 - 0.0030i

What am I doing wrong?

Thanks,

    Chris

On 7/13/2011 7:14 PM, Almohanad Fayez wrote:
  
Hey  Chris, if you reached this far I'm assuming that   
   the new packages have solved your issues ... 

Re: [Discuss-gnuradio] gr-dsp Library Block Parameters

[Almohanad Fayez]

Did you recompile the DSP code or did you download the the precompiled binary?  
I think there was an issue that I fixed in the DSP code but didn't update the 
binary.


al


-Original Message-
From: Christopher Dean 
To: Almohanad Fayez 
Cc: discuss-gnuradio 
Sent: Thu, Jul 14, 2011 11:12 am
Subject: Re: [Discuss-gnuradio] gr-dsp Library Block Parameters


Hi Al,

That really clears things up conceptually.  Thanks for the insight.

Given that, I went back and modified the dsp test case to use a scaling factor 
of 15, normalized input, and normalized output, so the block invocation was 
"dsp.fir_ccf (src_coeff, 15, 1, 0, 0, 0, 0)".  Running the test provides:

  -0.0102 - 0.0102i
  -0.0104 - 0.0103i
  -0.0105 - 0.0105i
  -0.0106 - 0.0106i
  -0.0107 + 0.0010i
   0.0111 + 0.0031i
   0.0334 + 0.0061i
   0.0671 + 0.0102i
   0.1122 + 0.0154i
   
However, this differs from the output of the gr.fir_filter_ccf block and the 
result of direct computation in MATLAB:

   0.0010 + 0.0111i
   0.0030 + 0.0334i
   0.0061 + 0.0671i
   0.0102 + 0.1122i
   0.0154 + 0.1689i
   0.0205 + 0.2255i
   0.0257 + 0.2822i
   0.0308 + 0.3388i
   0.0360 + 0.3954i

I've checked the magnitude and phase of each of these results, and it doesn't 
look like they're a simple rotation or multiple of each other.

I thought that it might just not work for decimal sources/coefficients, so I 
adjusted the tests so that src = (1,1,1,1,1,1,1,1,1) and src_coeff = 
(1,1,1,1,1).

Since we no longer needed to scale it before or after, our block invocation is 
"dsp.fir_ccf (src_coeff, 15, 1, 1, 1, 0, 0)".  This gives the output:

   1.0e+04 *

   3.2748 + 3.2751i
   3.2762 + 3.2752i
   3.2762 + 3.2767i
   3.2763 - 3.2768i
  -3.2768 - 0.0001i
0 - 0.0002i
0 - 0.0003i
0 - 0.0004i
0 - 0.0005i
0  
0  
0  
0  
0  
   2.8678 - 3.2752i
  -3.2757 - 3.2751i
  -3.2757 + 0.0001i
   0.0005 - 3.2768i
  -3.2768 
 
The output from the gr.fir_filter_ccf test is the first nine elements of the 
MATLAB output:  

 1
 2
 3
 4
 5
 5
 5
 5
 5
 
Finally, I thought that the issue might be that I'm not normalizing my source 
coefficients.  So, I normalized them in MATLAB, yielding src_coeff = (0.4472, 
0.4472, 0.4472, 0.4472, 0.4472), which provided the output:

   1.0e+03 *

   6.5440 + 6.5450i
   6.5500 + 6.5460i
   6.5500 + 6.5520i
   6.5510 + 6.5530i
   6.5530 - 0.0010i
0 - 0.0010i
0 - 0.0020i
0 - 0.0020i
0 - 0.0030i

What am I doing wrong?

Thanks,

Chris

On 7/13/2011 7:14 PM, Almohanad Fayez wrote: 
Hey Chris, if you reached this far I'm assuming that the new packages have 
solved your issues ... Since you're passing normalized values to the DSP you 
will need to scale them or they will be converted to zeros when moved to the DSP

float fixed
0.= 0
3.= 3
33.333= 33

so your scaling factor should be 15.  Regarding input/output signature it 
allows you to define if the input is normalized (signature = 0) meaning that 
the easycom-gpp library would need to scale it before transferring it to the 
dsp and the same for the output you'll tell it if it should scale it back to 
normalized numbers or should it keep it as fixed point numbers.  The motivation 
for this is the USRP1 with non-uhd drivers would provide fixed point data 
during receive mode and normalized data for transmit mode.



al





src_coeff, 0, 1, 0, 0, 0, 0) 
 









-Original Message-
From: Christopher Dean 
To: Almohanad Fayez 
Cc: discuss-gnuradio 
Sent: Wed, Jul 13, 2011 3:37 pm
Subject: gr-dsp Library Block Parameters


Hi Al, 
 
We're trying to use your gr-dsp library and are having difficulty verifying the 
output of your DSP.fir_ccf blocks. To allow for easy comparison to the standard 
filter type, gr.fir_filter_ccf, we generated a very simple block diagram in 
GRC. This consisted of a vector source, an fir_filter_ccf block, and a file 
sink. All of the original data and filter taps are the same, but the outputs 
are not lining up with their expected values. 
 
I have included the full script file at the bottom of this email. The relevant 
calls to the filter constructors are shown in the text. 
 
For instance: 
 
We have: 
 
src = (0.01+0.11j, 
  0.02+0.22j, 
  0.03+0.33j, 
  0.04+0.44j, 
  0.05+0.55j, 
  0.06+0.66j, 
  0.07+0.77j, 
  0.08+0.88j, 
  0.09+0.99j) 
 
src_coeff = (0.101, 0.102, 0.103, 0.104, 0.105) 
 
Without scaling (scaling_factor = 0, so scaling by 2^0 = 1): 
 
  gr.fir_filter_ccf(1, src_coeff) 
 
  This produces output: 
  0.0010 + 0.0111i 
  0.0030 + 0.0334i 
  0.0061 + 0.0671i 
  0.0102 + 0.1122i 
  0.0154 + 0.1689i 
  0.0205 + 0.2255i 
  0.0257 + 0.2822i 
  0.0308 + 0.3388i 
  0.0360 + 0.3954i 
 
  What we thought would be the equivalent call using the fir_ccf block is: 
 
 

Re: [Discuss-gnuradio] gr-dsp Library Block Parameters

[Almohanad Fayez]

 Hey Chris, if you reached this far I'm assuming that the new packages have 
solved your issues ... Since you're passing normalized values to the DSP you 
will need to scale them or they will be converted to zeros when moved to the DSP

float fixed
0.= 0
3.= 3
33.333= 33

so your scaling factor should be 15.  Regarding input/output signature it 
allows you to define if the input is normalized (signature = 0) meaning that 
the easycom-gpp library would need to scale it before transferring it to the 
dsp and the same for the output you'll tell it if it should scale it back to 
normalized numbers or should it keep it as fixed point numbers.  The motivation 
for this is the USRP1 with non-uhd drivers would provide fixed point data 
during receive mode and normalized data for transmit mode.



al





src_coeff, 0, 1, 0, 0, 0, 0) 
 

 

 


 

 

-Original Message-
From: Christopher Dean 
To: Almohanad Fayez 
Cc: discuss-gnuradio 
Sent: Wed, Jul 13, 2011 3:37 pm
Subject: gr-dsp Library Block Parameters


Hi Al, 
 
We're trying to use your gr-dsp library and are having difficulty verifying the 
output of your DSP.fir_ccf blocks.  To allow for easy comparison to the 
standard filter type, gr.fir_filter_ccf, we generated a very simple block 
diagram in GRC.  This consisted of a vector source, an fir_filter_ccf block, 
and a file sink.  All of the original data and filter taps are the same, but 
the outputs are not lining up with their expected values. 
 
I have included the full script file at the bottom of this email.  The relevant 
calls to the filter constructors are shown in the text. 
 
For instance: 
 
We have: 
 
src = (0.01+0.11j, 
0.02+0.22j, 
0.03+0.33j, 
0.04+0.44j, 
0.05+0.55j, 
0.06+0.66j, 
0.07+0.77j, 
0.08+0.88j, 
0.09+0.99j) 
 
src_coeff = (0.101, 0.102, 0.103, 0.104, 0.105) 
 
Without scaling (scaling_factor = 0, so scaling by 2^0 = 1): 
 
gr.fir_filter_ccf(1, src_coeff) 
 
This produces output: 
   0.0010 + 0.0111i 
   0.0030 + 0.0334i 
   0.0061 + 0.0671i 
   0.0102 + 0.1122i 
   0.0154 + 0.1689i 
   0.0205 + 0.2255i 
   0.0257 + 0.2822i 
   0.0308 + 0.3388i 
   0.0360 + 0.3954i 
 
What we thought would be the equivalent call using the fir_ccf block is: 
 
self.gr_fir_filter_xxx_0 = dsp.fir_ccf (src_coeff, 0, 1, 0, 0, 0, 0) 
 
This produces output: 
 
 0 
 0 
 0 
 0 
 0 
 0 
 0 
 0 
 0 
 
With scaling (scaling_factor = 15, so scaling by 2^15): 
 
gr.fir_filter_ccf(1, src_coeff) 
The data was manually scaled by 2^15 in MATLAB, producing output: 
 
   1.0e+04 * 
 
   0.0033 + 0.0364i 
   0.0100 + 0.1096i 
   0.0200 + 0.2199i 
   0.0334 + 0.3677i 
   0.0503 + 0.5533i 
   0.0672 + 0.7389i 
   0.0840 + 0.9245i 
   0.1009 + 1.1102i 
   0.1178 + 1.2958i 
 
dsp.fir_ccf (src_coeff, 15, 1, 0, 1, 0, 0) 
 
* output-signature = 1, so we want the output to be have the same scale 
factor that it is on the DSP. 
 
This produces output: 
 
   1.0e+03 * 
 
   0.3350 + 0.3350i 
   0.3400 + 0.3390i 
   0.3430 + 0.3440i 
   0.3470 + 0.3470i 
   0.3500 - 0.0340i 
  -0.3650 - 0.1000i 
  -1.0960 - 0.2000i 
  -2.1990 - 0.3350i 
  -3.6770 - 0.5030i 
 
In neither of these cases do the dsp implementation and the gpp implementation 
give the same output. 
 
I'm pretty sure that the issue is in my interpretation of your parameters.  
I've already been using the online documentation to figure out what the 
parameters do, so I know the basic jist of it, but obviously I haven't got it 
figured out yet.  Could you please explain the use of the scaling_factor, 
input_signature, and output_signature parameters in more detail? 
 
Also, for the input_signature parameter to be 0, like it is in the examples 
qa_fir_ccf2.py and qa_fir_ccf3.py, doesn't the input need to be normalized?  By 
my understanding, normalized vectors are unit vectors, so they should have 
length 1.  But src (above) has length 9, so it's not normalized and the 
input_signature parameter should be 1.  Is that correct? 
 
Thanks, 
 
Chris 
 
--- 
#!/usr/bin/env python 
## 
# Gnuradio Python Flow Graph 
# Title: Top Block 
# Generated: Wed Jul 13 11:09:34 2011 
## 
 
from gnuradio import eng_notation 
from gnuradio import gr 
from gnuradio.eng_option import eng_option 
from gnuradio.gr import firdes 
from optparse import OptionParser 
from gnuradio import dsp 
 
class top_block(gr.top_block): 
 
def __init__(self): 
gr.top_block.__init__(self, "Top Block") 
 

Re: [Discuss-gnuradio] Building GNU Radio/GRC on the E100

[Almohanad Fayez]

Since I don't have much experience running wxPython I'll leave it to someone 
more knowledgeable for commenting.  In regards to the configuration you'll have 
to be more specific about your issue ... is it that you want to build usrp1 
module and it's not building or is it some other component?  I like to use the 
"--enable-name-of-component" flag in the configuration step so configuration 
would fail when the missing dependency is discovered this way we can help you 
address that missing dependency.


Though if you're issue is building the usrp module then you should be using the 
UHD driver.





al fayez




-Original Message-
From: Christopher Dean 
To: discuss-gnuradio 
Sent: Fri, Jul 1, 2011 9:06 am
Subject: [Discuss-gnuradio] Building GNU Radio/GRC on the E100


Hi All,

I am currently trying to build GNU Radio for my E100, including GRC.  In 
the process, I've run into a few issues:

- We don't have wxPython in the opkg repository.  This is needed to use 
flowgraphs in GRC, and although there is a text interface, the flowgraph 
interface would be ideal.  I saw that somebody had actually managed to 
get flowgraphs in GRC on the E100, despite this.  How would I go about 
doing that?

- After the ./configure step, I received the following (see appended) 
list of components that are going to be skipped.  In the ./configure 
call, I disable volk, usrp2, usrp1, and gr-video-sdl.  The list that is 
output is much longer, but is it correct?  I haven't actually seen this 
documented anywhere.

- GRC still is not showing up as successfully configured.  I've followed 
the steps listed here 
(http://ettus-apps.sourcerepo.com/redmine/ettus/projects/usrpe1xx/wiki/FAQ#How-can-I-build-UHD-and-GNU-Radio-from-source)
 

and verified that I had all of the dependencies (excluding wxPython and 
xmlto) listed here 
(http://gnuradio.org/redmine/projects/gnuradio/repository/revisions/master/entry/README).
  

How do I fix this?

Thank you very much for your help.  Best,

Chris

Appendix:  Configuration Output


*
The following components were skipped either because you asked not
to build them or they didn't pass configuration checks:

usrp2-firmware

These components will not be built.


*
The following GNU Radio components have been successfully configured:

config
gruel
gnuradio-core
gr-msdd6000
gr-audio
gr-atsc
gr-cvsd-vocoder
gr-gsm-fr-vocoder
gr-noaa
gr-pager
gr-radio-astronomy
gr-trellis
gnuradio-examples
gr-uhd
docs

You my now run the make command to build these components.

*
The following components were skipped either because you asked not
to build them or they didn't pass configuration checks:

volk
gcell
usrp
usrp2
gr-usrp
gr-usrp2
gr-gcell
gr-comedi
gr-gpio
gr-radar-mono
gr-video-sdl
gr-wxgui
gr-qtgui
gr-sounder
gr-utils
grc

These components will not be built.

Configured GNU Radio release v3.4.0-3-g9bf36359 for build.


___
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

Re: [Discuss-gnuradio] To implement WiMAX with GnuRadio or not?

[Almohanad Fayez]

 

 I thought the 1 thread execution scheduler was deprecated in gnuradio?


 

 al fayez


-Original Message-
From: Michael Dickens 
To: Alexander Chemeris 
Cc: Gnuradio-discuss 
Sent: Sat, May 28, 2011 11:38 am
Subject: Re: [Discuss-gnuradio] To implement WiMAX with GnuRadio or not?


On May 28, 2011, at 11:26 AM, Alexander Chemeris wrote:
> 5) How well is GnuRadio suited for real-time operation?

In a general sense, yes, GNU Radio is well suited for real-time signal 
processing of data streams.  That said: "Real time" is only meaningful knowing 
the performance criteria.  What sort of performance do you require processing 
for?

> 5.1) Specifically - is memory allocated from heap with malloc() or it
> supports non-blocking memory pools?

IIRC (Tom? Eric?): GNU Radio uses the standard C++ "new" command for most 
memory 
allocations -- and thus it is memory from the heap.  One can always overload 
this method globally or locally if required, to provide memory from pools or 
other means.

> 5.2) Can the whole flowgraph be executed from a single thread to
> minimize cross-thread communication overhead (and jitter)?

Yes.  Your choices are a single thread for all or 1 thread per block. - MLD


___
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

Re: [Discuss-gnuradio] Questions about E100

[Almohanad Fayez]

For now I'd say there are two main approaches that can be taken for DSP 
development on the omap/davinci ... at least to the best of my knowledge.  
There is the DSPLink approach and the Codec Engine approach.  DSPLink provides 
the barebones mechanisms to enable inter-processor communication, setup, and 
data exchange.  I've steered away from Codec Engine because it seems more 
complicated and because from what I gather it's targeted more for situations 
where you might purchase a codec and only have access to the binary and you 
would need a mechanism to select and run between multiple codecs that might be 
available and for that Codec Engine would provide a framework to handle this 
situation.

If you're taking the DSPLink approach then the following are the set of tools 
you would need:

1- TI Code Generation Tools (CGT) C6000
the DSP Compiler
2- TI DSPLink
   to handle inter processor communication
3- TI Codec Engine
even if you're not using it you have install it because of dependency
4- TI DSP/BIOS
DSP RTOS
5- TI Local Power Manager (LPM)
The OMAP processor has a bug where you have to reset the DSP if you plan on 
loading different executables and the LPM modules provides an executable to do 
just that

You would need to setup the Makefiles for DSPLink before using it to point it 
to your kernel directory, compile tools, ... etc

al
-Original Message-
From: Alexander Chemeris 
To: Philip Balister 
Cc: discuss-gnuradio 
Sent: Fri, May 6, 2011 4:52 pm
Subject: Re: [Discuss-gnuradio] Questions about E100


On Fri, May 6, 2011 at 16:29, Philip Balister  wrote:
 On 05/05/2011 05:42 PM, Scott Johnston wrote:
>
> Hi,
>
> Has anybody out there done any development on the DSP? What tools are
> available to program it? I have used TI's code composer in the past to
> program DSPs, is there something comparable to that included with E100,
> or is it easy to get it? What I would like to be able to do is obtain
> common C libraries and compile C code to run on the DSP.

 You can build an image with dsp support by following the notes at:

 
http://ettus-apps.sourcerepo.com/redmine/ettus/projects/usrpe1xx/wiki/Install_OpenEmbedded

 I'll post a copy of the image next week.

 To run the demos, you'll need to modify the kernel boot args to create a
 memory hole. This is (barely) documented on the interwebs. Next time I
 update u-boot, I'll include an extra variable to make it easier to create
 the memory hole.
On a related question - have anyone tried SysLink on Gumstix/E100?
I'm just getting into this staff and trying to understand what tools
re the best to use for DSP on OMAP/DaVinci/Integra.
-- 
egards,
lexander Chemeris.
___
iscuss-gnuradio mailing list
iscuss-gnura...@gnu.org
ttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Questions about E100

[Almohanad Fayez]

I've done a fair amount of work with using the C64x+ DSP in and out of GNU 
Radio using the TI tools, you download my code and some custom gnuradio blocks 
for the omap processor based on the C64x+ DSP.  I've tested this code on a 
Beagleboard but it should work for the E100.

https://github.com/alfayez/gr-dsp

I recommend using the Linux tools for development and to use Code Composer for 
debugging ... I include a brief description of the tools you need to install to 
use the DSP my preference is to use DSPLink versus Codec Engine for GPP/DSP 
communication because it's simpler to program.  Good luck and feel free to send 
more detailed questions over the listserv once you start the work.

al fayez




-Original Message-
From: Brian Padalino 
To: Scott Johnston 
Cc: discuss-gnuradio 
Sent: Thu, May 5, 2011 6:17 pm
Subject: Re: [Discuss-gnuradio] Questions about E100


On Thu, May 5, 2011 at 6:07 PM, Brian Padalino  wrote:
 With a TI account, you can grab the free tools here:


https://www-a.ti.com/downloads/sds_support/TICodegenerationTools/download.htm
Also, another good resource for all TI processors seems to be:
http://processors.wiki.ti.com/index.php/Main_Page
Brian
___
iscuss-gnuradio mailing list
iscuss-gnura...@gnu.org
ttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Questions about E100

[Almohanad Fayez]

If you're interested modifying the base image beyond what's provided you'll 
need to get familiar with OpenEmbedded.  It's essentially a complete embedded 
framework for cross compilation, filesystem generation, and whatever embedded 
coolness you're interested in.  The E100 has a Gumstix Overo board which 
contains a TI OMAP3530 which contains an Armv7 GPP and a C64x+ Texas instrument 
fixed point DSP ... basically no x86.  you would need to get familiar with how 
to use OpenEmbedded to target the gumstix overo which is fairly well supported.

I know Philip is providing images which also allow you to download installation 
packages using opkg so people won't have to mess with OpenEmbedded ... I'll 
leave further commenting to Philip.

al fayez




-Original Message-
From: Marcus D. Leech 
To: discuss-gnuradio 
Sent: Thu, Apr 28, 2011 2:40 pm
Subject: Re: [Discuss-gnuradio] Questions about E100


On 28/04/2011 2:26 PM, Stefan Gofferje wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hi,

 as far as I understand, the E100 is a complete standalone system. I'm
 just a bit irritated by the descriptions "Console (USB)" and USB
 on-the-go. I assume, console USB is a serial console via some getty to
 ttyUSBx? How am I supposed to use it? Adaptor USB->Mini-USB and a
 USB-Serial adaptor?
 What is USB on-the-go?
SB on-the-go (OTG) is a USB standard that allows a USB port to adopt 
ither "host" or "device"
  personality, depending on application.  It's fairly common on 
mbedded-system platforms to
  supply this.
It's also *very* common for such embedded systems to provide a virtual 
erial-port via USB, by virtue of
  "looking" exactly like a USB serial port.  Such devices work with 
xisting Linux serial-port
  software, and as you observe will "manifest" as /dev/ttyUSBx or 
ometimes, /dev/ttyACMx.
> How about the software? Is the box x86 compatible or do I have to wait
 for Ettus to create some kind of software image if there is an update of
 gnuradio?
he E100 is based on an TI OMAP  platform.  Phil Ballister could fill in 
he details, but it ships with
  a Linux image pre-installed, and you can do either a cross-build or 
ative build of Gnu Radio yourself,
  and most E100 users do so.  It's completely end-user configurable, 
rogrammable, as you would expect
  any Linux platform to be.  But it's not X86.
> And finally - how about the performance? Does the box run X? Is it
 powerful enough to run grc-created WX-stuff?

t's not a desktop-class platform by any stretch of the imagination.
___
iscuss-gnuradio mailing list
iscuss-gnura...@gnu.org
ttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] User experience with E1x0 boards

[Almohanad Fayez]

I've always wondered about the design difference between the E100 and the work 
you did with Chris Anderson's board ... now I know.  BTW where do you have your 
driver code posted for the E100 and any documentation, if it exists yet :) ? I 
found slides that you presented on April 13th.

I want to get acquainted with what you did in hopes that I can get hold of an 
E100 this summer.

al fayez




-Original Message-
From: Philip Balister 
To: GNURadio Discussion List 
Sent: Fri, Apr 22, 2011 6:29 pm
Subject: Re: [Discuss-gnuradio] User experience with E1x0 boards


On 04/22/2011 06:00 PM, Almohanad Fayez wrote:

 I haven't worked with the E100 per se but I've worked with the Beagleboard + 
SRP1 which is the same thing except the E100 uses SPI to communicate with the 
rocessor versus USB.  So I've done work on integrating the OMAP3530 DSP with 
he GPP within GNU Radio.  I feel that the use of the DSP is a MUST to make the 
ost out of the E100 and with my Beagleboard + USRP setup I was able to run some 
M flowgraphs but one of my bottlenecks was the USB USRP interface which the 
100 would definitely fix.
Al points are good, except the E100 uses the GPMC bus to communicate 
ith the FPGA. 16 bit wide data bus instead of 1 :)
Philip
>
 Basically with the E100 I feel that you need to get your hands "dirty" where 
ou might need to rewrite some GNU Radio components to make use of the NEOS 
oprocessor, which Philip Balister has done some good work in that respect, and 
ou would also need to make use of the C64x+ DSP which I can point you to the 
ource code I've developed.

 The E100 has a lot of untapped potential at the moment and I hope to see more 
omentum in working with the NEOS and DSP which is what I'm focusing on and 
illing to help people to get started on.


 al fayez


 -Original Message-
 From: Colby Boyer
 To: GNU Radio Discussion
 Sent: Fri, Apr 22, 2011 5:43 pm
 Subject: [Discuss-gnuradio] User experience with E1x0 boards


 Hi All,
 My lab is interested in purchasing some USRPs. It is pretty settled
 hat some of the boards will be the N2x0 series, but I am interested
 o hear from people who have used the E1x0 boards. From what I can
 ell, the E1x0 board should have better latency performance than the
 2x0 and should have a better interface with the FPGA (GPIO pins);
 lso, it has an onboard DSP. It seems that the latency would be the
 ain motivation for the product, from an experimental point of view.
 Has anyone tried integrating processing on the FPGA and DSP to get
 etter latency results? Your thoughts on the board versus the N2x0?
 If you want to take the discussion off list, feel free to.
 Thanks,
 olby
 ___
 iscuss-gnuradio mailing list
 iscuss-gnura...@gnu.org
 ttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio





 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
iscuss-gnuradio mailing list
iscuss-gnura...@gnu.org
ttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] User experience with E1x0 boards

[Almohanad Fayez]

I haven't worked with the E100 per se but I've worked with the Beagleboard + 
USRP1 which is the same thing except the E100 uses SPI to communicate with the 
processor versus USB.  So I've done work on integrating the OMAP3530 DSP with 
the GPP within GNU Radio.  I feel that the use of the DSP is a MUST to make the 
most out of the E100 and with my Beagleboard + USRP setup I was able to run 
some FM flowgraphs but one of my bottlenecks was the USB USRP interface which 
the E100 would definitely fix.

Basically with the E100 I feel that you need to get your hands "dirty" where 
you might need to rewrite some GNU Radio components to make use of the NEOS 
coprocessor, which Philip Balister has done some good work in that respect, and 
you would also need to make use of the C64x+ DSP which I can point you to the 
source code I've developed.

The E100 has a lot of untapped potential at the moment and I hope to see more 
momentum in working with the NEOS and DSP which is what I'm focusing on and 
willing to help people to get started on.


al fayez


-Original Message-
From: Colby Boyer 
To: GNU Radio Discussion 
Sent: Fri, Apr 22, 2011 5:43 pm
Subject: [Discuss-gnuradio] User experience with E1x0 boards


Hi All,
My lab is interested in purchasing some USRPs. It is pretty settled
hat some of the boards will be the N2x0 series, but I am interested
o hear from people who have used the E1x0 boards. From what I can
ell, the E1x0 board should have better latency performance than the
2x0 and should have a better interface with the FPGA (GPIO pins);
lso, it has an onboard DSP. It seems that the latency would be the
ain motivation for the product, from an experimental point of view.
Has anyone tried integrating processing on the FPGA and DSP to get
etter latency results? Your thoughts on the board versus the N2x0?
If you want to take the discussion off list, feel free to.
Thanks,
olby
___
iscuss-gnuradio mailing list
iscuss-gnura...@gnu.org
ttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Agile Solutions is Pleased to announce USRP STAR. Yet another addition to GNURADIO

[Almohanad Fayez]

As a user and would be developer on the gnuradio list it's always exciting to 
hear about the availability for new products which can be used with gnuradio, 
such as the FUNcube dongle and the work Alex did to support it and the Agile 
solution platform.  Product developer support for users on this listserv has 
been instrumental to the success of GNU Radio and the mutual respect between 
the product developers has always kept this listserv focused on productivity.



If a new product is better is thought to be suited than an older product for 
specific applications, I would hope to see a thorough discussion and analysis 
in literature, for example the Wireless Innovation Forum is an excellent venue 
for such work, versus an email.  An email discussion on this subject can seem 
like a marketing tool which I'm sure is not the actual goal.

This is more of a user perspective and I think the more key developers would 
agree on this expectation from the listserv.


al fayez



-Original Message-
From: info 
To: Matt Ettus ; discuss-gnuradio Discussion Group 

Sent: Tue, Apr 19, 2011 4:10 pm
Subject: Re: [Discuss-gnuradio] Agile Solutions is Pleased to announce USRP 
STAR. Yet another addition to GNURADIO


On Mon, 18 Apr 2011 12:17:22 -0700, Matt Ettus  wrote:
 On 04/18/2011 10:13 AM, i...@agile-sdr-solutions.com wrote:
> We went through this published article you sent to us for review
> http://newport.eecs.uci.edu/~hyousefi/publ/sdrMC08.pdf
>
> We didn't see anything particular to STBC/SFBC.
 
 http://lmgtfy.com/?q=usrp+stbc+filetype%3Apdf
 
> For a beamformong
> system phase coherence is the fundamental requirement. By varying
> phase(weighting the antenna co-efficient) we can steer the beam. In
> USRP1/2/200/210 there is no guarantee of the phase reference every time
> you send the packets for transmitting or receiving. Every packet
> transmission they start with arbitrary phase.
 
 That is fundamentally incorrect.  Every packet will NOT start with
 arbitrary phase.  All of our systems have been used for beamforming.
 All beamforming systems need calibration and the USRP is no different.
 Here are some examples:
 
 http://lmgtfy.com/?q=usrp+beamforming+filetype%3Apdf
 
> So every time the beam
> will be switching in arbitrarily. Particularly transmitter DAC doesn't
> have control over the phase plus deviation in the LO phase lock with
> track length of the common clock. And for for a phased array system,
> DOA(Direction of arrival) depends on the phase reference of the system.
> So every time the phase reference needs o be tracked in the algorithm to
> know actual DOA. For a diversity transmitter and diversity receiver
> employing MRC would only be realized with USRP1 system as per our
> understanding.
 
 That is incorrect.  The USRP will maintain a constant phase relationship
 between antennas for as long as you leave it running.
 
> We would like to know if USRP1 is capable of these things and how ?
 
 Yes.  I have answered the question of how to do this many times on this
 mailing list over the years.
 
> Although we haven't come across any projects with USRP1 for successful
> testing for STBC and SFBC codes.
> If any team or individual has published this work, we would be happy to
> check that part.
 
 Steve answered that for you, and you can find a lot more at the link I
 sent above.
 
> To verify from our end we took IQ samples for 2x2 Almouti scheme from
> Agilent-VSA example files.
> We have then transmitted and received these IQ samples via
> USRP1+RFX2400. Transmission and reception done at 1MSPS with 4x
> interpolation.
> Received IQ samples when loaded into VSA for analysis, it failed to
> demodulate and decode. We have used Agilent VSA for years now and we
> consider it as a golden reference for demodulation and decoding.
>
> We respect your timely suggestions and advice.
 
 Tom and I wrote Alamouti OFDM code and used it on USRPs in my office.
 You can find some other people who did the same here:
 
 http://lmgtfy.com/?q=alamouti+usrp+filetype%3Apdf
 
 Matt Ettus
Dear Matt,
We honestly went through every material in search on Google but we
ouldn't locate a single article published successful testing for
TBC/SFBC. 
For whatever reason, we would like to know, if you can confirm on this
ith your lab setup ?
e have done considerable experimental work on this. And we are certain
ith the results we have have found. 
e would encourage this exploration in best interest of all from your
nd. 
Thank you.

__
iscuss-gnuradio mailing list
iscuss-gnura...@gnu.org
ttp://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] UHD Driver in E100/Beagleboard

[Almohanad Fayez]

I think I made some progress in diagnosing the UHD/Beagleboard USRP1 issue.  
I've tried bitbaking Philip's GNU Radio 3.2.1 recipe and the compilation fails 
because of the libusb-0.1.12 link, more specifically the "libusb-gnur.a" 
library.  For some reason GCC is expecting the library to have the "-fPIC" flag 
passed when building the library which doesn't make sense since it's trying to 
link against a static library and not a shared librar ... it was complaining 
about an ARM_MOV or something like that assembly command.  To my understanding 
the libtool included in the libusb should make sure that such confusion doesn't 
happen which in using GCC 4.3 was not an issue but with the GCC 4.5 included in 
the new tree is an issue.

I also tried incorporating the libusb fix against the GNU Radio GIT recipe but 
the configure stage fails because gnuradio can't find the "USB_BULK_WRITE" 
function in the libusb library from libusb-0.1.12 which when I looked is 
actually there.  When I bypass the configure check for USB_BULK_WRITE the 
gnuradio compilation fails at the same stage as gnuradio 3.2.1.  I feel like 
the libusb-0.1.12 static library is corrupt for some reason more specifically I 
think libtool might be the culprit.

I assume that USB_BULK_WRITE is used in the USRP sink UHD block which might 
explain why I can receive but I can't write using the UHD driver.  The 
libusb-0.1.12 fix included in the UHD driver, did it use GCC 4.5? did it use 
libusb-0.1.12? an older or newer version maybe?  did it use a different 
libtool?  

I need to find a way to pass the -fPIC flag to the configure stage of 
libusb-0.1.12 unfortunately I can't seem to find an easy way to do it and I'm 
about to head out of town for a few days.  Other than that doese anyone have 
any suggestion?  

Josh or Philip :)

al fayez




-Original Message-
From: Almohanad Fayez 
To: philip 
Cc: discuss-gnuradio 
Sent: Thu, Feb 24, 2011 6:42 pm
Subject: Re: [Discuss-gnuradio] UHD Driver in E100/Beagleboard


1- I'm using the host USB not the OTG
2- I'm using the 2.6.37 kernel with Angstrom 2010
3- The following is the dmesg output which looks ok ... at least to me :)

[  108.369293] usb 1-2.3.1: USB disconnect, address 4
[  108.770874] usb 1-2.3.1: new high speed USB device using ehci-omap and 
address 6
[  108.889404] usb 1-2.3.1: New USB device found, idVendor=fffe, idProduct=0002
[  108.889434] usb 1-2.3.1: New USB device strings: Mfr=1, Product=2, 
SerialNumber=6
[  108.889465] usb 1-2.3.1: Product: USRP Rev 4
[  108.889465] usb 1-2.3.1: Manufacturer: Free Software Folks
[  108.889495] usb 1-2.3.1: SerialNumber: 4bd1d69b




I think I'll try to attempt to redo your libusb hack by copying it from the 
older gnuradio recipes and attempt to use the original USRP USB driver if the 
problem ends up being too major ... unless you want to do that as a favor to me 
and push the recipe into the openembedded tree !!!   pretty please :)


al fayez






-Original Message-
From: Philip Balister 
To: Almohanad Fayez 
Cc: discuss-gnuradio 
Sent: Thu, Feb 24, 2011 2:20 pm
Subject: Re: [Discuss-gnuradio] UHD Driver in E100/Beagleboard


On 02/23/2011 11:25 PM, Almohanad Fayez wrote:

> I was wondering about people's experience with the UHD driver on the E100 or 

the Beagleboard.  I am able to use it to receive IQ data from the USRP but I 

can't seem to transmit anything from it ... if I take the same flowgraph to a 

laptop I'm able to transmit IQ using the same USRP/daughterboard and the UHD 

driver however when I try to run the same transmitter on the Beagleboard and I 

check my spectrum analyzer I don't see anything

>

> I already did a signal capture before sending to the USRP and made sure that 

there is data getting pushed through ... is there a problem with UHD/USRP 

sinking on the E100 and the Beagleboard ???  I also made sure that I'm using 
the 

latest UHD firmware on the beagleboard.

>

>

> The following is the version info printed when I run the flowgraph:

> linux; GNU C++ version 4.5.3 20110214 (prerelease); Boost_104500; 

UHD_0001.20110224034946.1


Al,


Which USB port are you using to connect the USRP1? What kernel version?


Can you run dmesg and see if there are any usb related messages at the end?


Philip




___
iscuss-gnuradio mailing list
iscuss-gnura...@gnu.org
ttp://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] FM Receiver

[Almohanad Fayez]

 

 I have run into this problem on the Beagleboard ... here's my explanation for 
what I think is happening and the fix.  What's happening is GNU Radio is trying 
to run as a real time thread which if you're root or you've given your Linux 
username permission to have rtprio privileges but for some reason I also ran 
into the problem where I can't get realtime scheduling privileges.

The parametes of interest to fix this problem are 

cat /proc/sys/kernel/sched_rt_runtime_us
output = 95


 cat /proc/sys/kernel/sched_rt_period_us
output = 100

 
now sched_rt_period_us controls the scheduling period in your processor and 
sched_rt_runtime_us controls how much of that period is reserved for realtime 
processing.  When you read the associated driver documentation it says to 
disable this segmenting for the realtime period partitioning you need to set 
sched_rt_runtime_us to -1 or you can completely disable this feature in your 
kernel by "make menuconfig" in your kernel driver directory ... my preference 
is not to mess with drivers so I set it to -1 with

echo -1 > sched_rt_runtime_us

now when you run 
cat /proc/sys/kernel/sched_rt_runtime_us
output = -1

Now you should be able to use realtime scheduling in GNU Radio.  I'm not sure 
if this is a good fix because it might give background processes realtime 
privileges which would defeat the purpose of the realtime designation ... for 
me I'm running console Linux on the Beagleboard so it's an acceptable solution. 
 As an alternative approach you might try to use the Linux "nice" and "renice" 
programs to tweak thread priority but I personally wans't successful with this 
approach.


al fayez


-Original Message-
From: Anoth 
To: Discuss-gnuradio 
Sent: Thu, Feb 24, 2011 6:59 pm
Subject: [Discuss-gnuradio] FM Receiver




Hi



I am using an USRP N210 with GNU radio, UHD and GRC on Ubuntu 10.10. I have

connected a WBX daughterboard to the USRP. I want to receive and, of course,

listen the radio thanks to this system. I have built a flow graph and when I

execute it, I only heard noise and can see this message in the terminal :



linux; GNU C++ version 4.4.5; Boost_104200; UHD_002.20110206225409.aea6ac1



>>> gr_fir_fff: using SSE

Current recv sock buff size: 5000 bytes



Warning:

error in pthread_setschedparam

Failed to set thread priority 0.5 (realtime):

Performance may be negatively affected.

See the general application notes.



Warning:

error in pthread_setschedparam

Failed to set thread priority 0.5 (realtime):

Performance may be negatively affected.

See the general application notes.

mboard0 MIMO master



Warning:

error in pthread_setschedparam

Failed to set thread priority 0.5 (realtime):

Performance may be negatively affected.

See the general application notes.

>>> gr_fir_ccc: using SSE

aUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaU



I have looked on the internet and tried different things but nothing has

changed. Could someone give me an hand to solve with problem ?



Thank you very much,



Francois

-- 

View this message in context: 
http://old.nabble.com/FM-Receiver-tp31009069p31009069.html

Sent from the GnuRadio mailing list archive at Nabble.com.





___

Discuss-gnuradio mailing list

Discuss-gnuradio@gnu.org

http://lists.gnu.org/mailman/listinfo/discuss-gnuradio




 
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] UHD Driver in E100/Beagleboard

[Almohanad Fayez]

1- I'm using the host USB not the OTG
2- I'm using the 2.6.37 kernel with Angstrom 2010
3- The following is the dmesg output which looks ok ... at least to me :)

[  108.369293] usb 1-2.3.1: USB disconnect, address 4
[  108.770874] usb 1-2.3.1: new high speed USB device using ehci-omap and 
address 6
[  108.889404] usb 1-2.3.1: New USB device found, idVendor=fffe, idProduct=0002
[  108.889434] usb 1-2.3.1: New USB device strings: Mfr=1, Product=2, 
SerialNumber=6
[  108.889465] usb 1-2.3.1: Product: USRP Rev 4
[  108.889465] usb 1-2.3.1: Manufacturer: Free Software Folks
[  108.889495] usb 1-2.3.1: SerialNumber: 4bd1d69b


 

 I think I'll try to attempt to redo your libusb hack by copying it from the 
older gnuradio recipes and attempt to use the original USRP USB driver if the 
problem ends up being too major ... unless you want to do that as a favor to me 
and push the recipe into the openembedded tree !!!   pretty please :)


al fayez


 

 

-Original Message-
From: Philip Balister 
To: Almohanad Fayez 
Cc: discuss-gnuradio 
Sent: Thu, Feb 24, 2011 2:20 pm
Subject: Re: [Discuss-gnuradio] UHD Driver in E100/Beagleboard


On 02/23/2011 11:25 PM, Almohanad Fayez wrote:

> I was wondering about people's experience with the UHD driver on the E100 or 

the Beagleboard.  I am able to use it to receive IQ data from the USRP but I 

can't seem to transmit anything from it ... if I take the same flowgraph to a 

laptop I'm able to transmit IQ using the same USRP/daughterboard and the UHD 

driver however when I try to run the same transmitter on the Beagleboard and I 

check my spectrum analyzer I don't see anything

>

> I already did a signal capture before sending to the USRP and made sure that 

there is data getting pushed through ... is there a problem with UHD/USRP 

sinking on the E100 and the Beagleboard ???  I also made sure that I'm using 
the 

latest UHD firmware on the beagleboard.

>

>

> The following is the version info printed when I run the flowgraph:

> linux; GNU C++ version 4.5.3 20110214 (prerelease); Boost_104500; 

UHD_0001.20110224034946.1



Al,



Which USB port are you using to connect the USRP1? What kernel version?



Can you run dmesg and see if there are any usb related messages at the end?



Philip




 
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] UHD Driver in E100/Beagleboard

[Almohanad Fayez]

I was wondering about people's experience with the UHD driver on the E100 or 
the Beagleboard.  I am able to use it to receive IQ data from the USRP but I 
can't seem to transmit anything from it ... if I take the same flowgraph to a 
laptop I'm able to transmit IQ using the same USRP/daughterboard and the UHD 
driver however when I try to run the same transmitter on the Beagleboard and I 
check my spectrum analyzer I don't see anything 

I already did a signal capture before sending to the USRP and made sure that 
there is data getting pushed through ... is there a problem with UHD/USRP 
sinking on the E100 and the Beagleboard ???  I also made sure that I'm using 
the latest UHD firmware on the beagleboard.


The following is the version info printed when I run the flowgraph:
linux; GNU C++ version 4.5.3 20110214 (prerelease); Boost_104500; 
UHD_0001.20110224034946.1


thanks

al fayez

 

 


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] USRP source + UHD driver and data formatting

[Almohanad Fayez]

 

 Did the USRP IQ data format change in the UHD driver?  The data from the USRP1 
used to be 15-bit fixed point, or something like that, is it now normalized 
floating point data?  I'm asking because I have code that moves data from the 
USRP to a Fixed-point DSP and it seems I have to redo the data conversion part 
so can someone explain to me the new IQ data format?  

Also is this the same data format expected for the USRP sink?

thanks

al fayez


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Any E100/Beagleboard users running into realtime scheduling issues?

[Almohanad Fayez]

Out of curiosity are there any USRP E100 users running into problems enabling 
realtime scheduling?  On my beagleboard I am not able to use realtime 
scheduling since upgrading to the latest kernel and Angstrom.  Apparently there 
is an issue with realtime scheduling being done on per group basis or something 
like that, which is weird since I was doing everything as root.

Anyways I managed to fix this issue by

echo -1 > /proc/sys/kernel/sched_rt_runtime

which apparently was reserving 95% of the CPU time for realtime threads which 
even as root I wasn't able to access.  Anyways, I'm interested from hearing if 
someone else faced this and if there's a neater solution


al fayez





___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] USRP E100 + cheap TI Davinci combo ??

[Almohanad Fayez]

Out of curiosity, does anyone know of a cheap <$400 Davinci board with 
something like a DM6446 processor?  I've been reading a little about the Texas 
Instrument proprietery high speed serial interface (VLYNQ) which is found on 
Davnici processors but not OMAPs such as the case with the E100.  I have a gut 
feeling that it might be the same interface used in the Sundance and Lyrtech 
platforms for high speed FPGA/DSP communication.  Apparently TI also provides 
info about how to implement FPGA cores if you don't want to shell out money for 
the Xilinx or Altera provided cores.  Anyways I'm trying to figure out if such 
interface can provide higher RF data transfer rates and if there's a cheap EVM 
with a Davinci which can (potentially) be plugged into a USRP (a la USRP E100) 
basically as a higher bandwidth more processing for people.  

I'm curious what other people might think about this!

al 



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] TPB Scheduler - Block Scheduling Rate

[Almohanad Fayez]

 I've been down this path before Ben and I can tell you it's a very dark and 
lonely path, biggest advice is to use GDB my preference is to use DDD.  I 
personally found it easier to start tracing from the python source file there's 
a way where you can select the PID of your python process from GDB.  Anways, 
you'll end up seeing a lot more BOOST and SWIG information than you can ask for 
but I really think it's the best way to do it.

Also if you can document what you see in terms of function/file call sequences 
it would be great ! i know that at least I would appreciate it.  good luck

 


 al fayez

 

-Original Message-
From: Ben Hilburn 
To: GNURadio Discussion List 
Sent: Fri, Jan 28, 2011 4:17 am
Subject: [Discuss-gnuradio] TPB Scheduler - Block Scheduling Rate


Hey all -

I'm running some experiments, and would like to directly tune the rate
that the TPB scheduler is switching between blocks.  I've dug around a
bit, and can't seem to find the relevant portions of code; I've never
looked at this part of GNURadio before, and the gruel / boost mix is
slightly hard to follow.

Has anyone tried anything like this before, or can someone point me in
the direction of the relevant source file?

Thanks!

Cheers,
Ben

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


 
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] TI vs Freescale DSP for open-source development

[Almohanad Fayez]

 okay here are my 2 cents

2- TI actually offers all the tools you need to develop for their DSP for free, 
I can vouch for the C64x+ DSP since that's what I have experience using.  You 
can download and look at the supported DSP for the free download from
http://software-dl.ti.com/dsps/dsps_registered_sw/sdo_sb/targetcontent/

 
The biggest issue you might run into with the free software is the ability to 
use a JTAG, if you want to use a JTAG you have to use Code Composer period.  
Though I've read about people using the free demo version of Code Composer 
(CCS) 4.0 with a very cheap JTAG ( < $150) to debug their DSP code.  I think TI 
restricts the type of DSPs and JTAGs you can use with the free CCS I know that 
the JTAG I use (XDS560) is not supported.

3- TI support for open source is surprisingly decent.  I've posted many 
questions on their support forums and TI engineers have always gotten back to 
me with alot of good information and continued asnwering as posted more follow 
up questions.


 

 4- The learning tool has a bit of a learning curve that's for sure.  I have 
posted a github link on the listserv yesterday which includes new custom blocks 
for GNU Radio using the C64x+ DSP.  You might find the guide helpful in 
shedding some light about developing with TI tools.

6- I've been using TI software as an open source developer for almost 1.5 years 
now and I think they've managed to find a great balance between being a for 
profit company and a supplier of tools for the open source community.  I don't 
have experience with freescale but my experience with TI has been a positive 
one.


al fayez



-Original Message-
From: Alexander Chemeris 
To: Gnuradio-discuss 
Sent: Fri, Jan 28, 2011 10:24 am
Subject: [Discuss-gnuradio] TI vs Freescale DSP for open-source development


Hello all,

We're working on an open-source WiMAX receiver/scanner and we're
looking into using a high-performance DSP to process data from USRP.
Right now we implement this processing in FPGA, but we want to
experiment with DSPs too. I know there are skilled people here and I'm
looking forward to hear their opinion.

Note, that this project is not meant for starving students or
occasional hobbyists. It is for high-profile hobbyists, targeted
researchers and for small companies. So please refrain from comments
like "no way, this is too expensive for 90% of community". Though we
would appreciate comments on how to make it cheaper.

So, I'm looking for the community advise about pros and cons of
different DSPs. Particularly I'm interested in comparing Freescale
MSC815x/MSC825x [1][2][3] and TI TMS320C667x [4][5] DSPs/SoCs from the
perspective of open-source development. But if you know any other good
 high-profile DSPs - please propose them too. So far, as I read it we
have following comparison:

1) Price.
It used to be that Freescale is cheaper, but right now I see that
"pricing for the MSC8156 starts at $192 in 10,000 unit quantities"
[6], while TMX320C6670CYP is priced 160.00 USD | 1ku [7]. So they're
barely the same with TI slightly winning. I'm not sure how much will
new MSC8157 cost.

2) Development tools price
Both Freescale CodeWarrior and TI Code Composer seem to be at the same
line with about $2K per single license (correct me if I'm wrong - I
may have missed something easily).

Big minus here is that neither Freescale nor TI offer open/free
compilers for their DSPs, which is a big roadblock for open-source
development.

3) Support for open-source technologies.
Well, both Freescale and TI declare themselves as more or less
open-source supporters (which is weird while they have expensive
development tools). Both offers BSPs for Linux for GPP part of SoCs
and free/open OSes for DSP cores (SmartDSP for Freescale, SYS/BIOS for
TI). I would appreciate if someone could comment on maturity of those
and their usability (bug-ness level).

Other then that I don't see any evidence of their support for
open-source for their DSPs.

4) Quality/simplicity
I have no experience with those DSPs yet, so I would very much
appreciate comments about development tools quality / easy to use,
code generation quality, DSP architecture simplicity for a programmer
and (important!) documentation quality.

5) Chips availability
I'm a software guy, so again I seek for an insight about availability
of Freescale and TI DSPs. How hard is it to source them? Especially
outside of US?

6) Any other concerns?
Please share your opinion - I should have missed something important.
It's hard to keep everything in mind.

PS As I told, we're working on an open-source WiMAX receiver right
now. If you're a skilled engineer and you're willing to participate -
drop me a few lines with your experience description. We need more
skilled hands to get up and running faster. And I should say this
project is a *lot* of fun.
PPS Please don't mail me if you just want to look into the code out of
curiosity or don't have enough skills or enough time to help. We'll

[Discuss-gnuradio] Available GNU Radio DSP support for TI OMAP (e.g. Beagleboard & USRP E100)

[Almohanad Fayez]

Hi, I've been working for a while now on adding DSP support for GNU Radio using 
OMAP processors, specifically OMAP3530 which has a fixed point C64x+ DSP.  The 
following is a github for interested people to download it:

git://github.com/alfayez/gr-dsp.git

I don't have a USRP E100, I use a Beagleboard, but things should work out the 
same.  I've just recently upgraded to the Angstrom 2010 and the 37 kernel and 
to the best of my knowledge things are working smoothly.  I've done over the 
air testing with USRP 1's but haven't used the UHD driver with it but that 
shouldn't matter.  I'd be interested in user feedback especially E100 users.

almohanad (al) fayez
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Problem with valve and audio sink

[Almohanad Fayez]

try running the same fix with the static variable, this problem will show up 
even with simple setups because it's in the alsa audio source block.  even 
though the fix works i wouldn't recommend it for long term solution because 
it's a hack.  you can look into the FIXME section of the code to make a more 
permenant solution.


al


-Original Message-
From: Volker Schroer 
To: Discuss-gnuradio 
Sent: Mon, Dec 6, 2010 11:40 am
Subject: [Discuss-gnuradio] Problem with valve and audio sink


Hi all,
I get an runtime error, when switching a valve.
I saw a similar problem some months ago, but the setup was different.
My setup is quite easy:
A signal source ( cosine, float ) connected to a audio sink.
he same signal source is connected to a valve and the valve is 
onnected to a scope sink.
The valve is switched by a checkbox.
Switching the valve leads to
audio_alsa_sink[hw:0,0]: snd_pcm_hw_params failed: File descriptor in 
ad state
erminate called after throwing an instance of 'std::runtime_error'
  what():  check topology failed on audio_alsa_sink(1) using ninputs=1, 
outputs=0
I wonder how the valve affects the audio sink.
Any ideas ?
Thanks in advance
Volker
___
iscuss-gnuradio mailing list
iscuss-gnura...@gnu.org
ttp://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Re: remark on custom block + python behavior on Beagleboard

[Almohanad Fayez]

 

 The beagleboard wasn't complaining about the RTC but I installed a battery on 
the beagleboard expansion yesterday hoping that'll fix it, renewed the 
timestamps by "touching" everything but that didn't seem to help.  The problem 
gets more complicated as the code i'm working with is composed of a python file 
importing other custom python files.  The best fix I found is turning off PYO 
and PYC file generation all together using "export PYTHONDONTWRITEBYTECODE=1".  
I've read a number of posts for other projects complaining about stale pyo/pyc 
corrupting applications I'm installing and running everything as root so I 
doubt file permissions is the culprit,

 I'm currently using Python 2.6 on the beagleboard, I plan on upgrading to 2.8 
soon and see if the problem persists ... at least for now the environmental 
variable is good enough


al


 

 

-Original Message-
From: Philip Balister 
To: discuss-gnuradio 
Sent: Tue, Oct 26, 2010 1:48 pm
Subject: [Discuss-gnuradio] Re: remark on custom block + python behavior on 
Beagleboard


On 10/25/2010 04:38 PM, Almohanad Fayez wrote:
> Hi,  sent an email a while back about what I thought was a scheduler issue 
with gnuradio on the beagleboard.  Basically I've been writing custom GNU Radio 
block for the OMAP's DSP and running them on the beagleboard.  On occassions 
when I'm running multiple blocks, GNU Radio would parse my flowgraph but then 
get lost and never starts the flowgraph.  I've always thought it was an issue 
with my code but it turned out to be a python issue and I'm not sure if it's 
specific to my platform or python in general.
>
> python  basically generates optimizied pre-interpred python files  *.pyo and 
*.pyc. and as it happens, some of these files are not refreshed when I make 
changes to my python source file I managed to debug the issue where at the 
point 
where gnuradio calls the c++ file that handles the swig call handling 
"gnuradio_swig_py_runtime.cc".  This file is able to detect the python block so 
the "custom_blocks.cc" file generated by the howto-write-a-custom-block auto 
tools.  then there is a call placed to the constructor "gr_basic_block.cc" and 
that's where gnuradio gets lost into oblivion.
>
> I was able to finally fix this problem by writing a script that deletes all 
> of 
the pyc and pyo files associated with my library and flowgraph.  my question 
is, 
is this a know python issue, an issue with the custom gnuradio block, or an 
issue with the platform?  I managed to recreate this problem using the custom 
block 3.2.1 and 3.2.2 templates and I was also able to recreate it by using the 
original how to square a number example.

Are you having real time clock issues? If you do not have the battery on 
your beagle, it will reset time each time you cycle power. That could 
explain what you are seeing. I installed the battery backup on mine to 
avoid this problem. You can also try to set the time over the network.

Philip

>
> thanks.
>
> al
>
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


 
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] remark on custom block + python behavior on Beagleboard

[Almohanad Fayez]

Hi,  sent an email a while back about what I thought was a scheduler issue with 
gnuradio on the beagleboard.  Basically I've been writing custom GNU Radio 
block for the OMAP's DSP and running them on the beagleboard.  On occassions 
when I'm running multiple blocks, GNU Radio would parse my flowgraph but then 
get lost and never starts the flowgraph.  I've always thought it was an issue 
with my code but it turned out to be a python issue and I'm not sure if it's 
specific to my platform or python in general.

python  basically generates optimizied pre-interpred python files  *.pyo and 
*.pyc. and as it happens, some of these files are not refreshed when I make 
changes to my python source file I managed to debug the issue where at the 
point where gnuradio calls the c++ file that handles the swig call handling 
"gnuradio_swig_py_runtime.cc".  This file is able to detect the python block so 
the "custom_blocks.cc" file generated by the howto-write-a-custom-block auto 
tools.  then there is a call placed to the constructor "gr_basic_block.cc" and 
that's where gnuradio gets lost into oblivion.

I was able to finally fix this problem by writing a script that deletes all of 
the pyc and pyo files associated with my library and flowgraph.  my question 
is, is this a know python issue, an issue with the custom gnuradio block, or an 
issue with the platform?  I managed to recreate this problem using the custom 
block 3.2.1 and 3.2.2 templates and I was also able to recreate it by using the 
original how to square a number example.

thanks.

al 
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] audio_alsa: problem with "valve" at head of audio_alsa sink sub-graph

[Almohanad Fayez]

 
 Marcus, this is a problem with the 
gnuradio/gr-audio-alsa/src/audio_alsa_source.cc.  I ran into a few weeks ago 
and i managed to find a quick and dirty fix for.   

I'm assuming that you're stopping the flow graph and restarting itagain. if you 
look into the "check_topology" method.  There's a FIXMEthere, what I beleieve 
is happening, is that when you try to restartthe flowgraph after stopping it 
GNU Radio is trying to reset  yoursound card and it thinks that it's in a 
corrupt state.  

My fix was to add a "static bool" variable that skips 
the"snd_pcm_hw_params(d_pcm_handle, d_hw_params);" function call.  theflag is 
"static" just so you can detect your first entry.  After thatrun make and make 
install and things should work fine.


al

 
 


 

 

-Original Message-
From: Marcus D. Leech 
To: Discuss-gnuradio 
Sent: Sat, Oct 23, 2010 4:17 pm
Subject: [Discuss-gnuradio] audio_alsa: problem with "valve" at head of 
audio_alsa sink sub-graph


In my application I have a sub-graph that terminates an an audio_alsa sink.

At the "head" of this sub-graph, I've placed a valve, so that I can turn
off data being
  copied to the audio_alsa sink.

When this valve transitions from "closed" (data flowing) to "open" (data
*not* flowing), it provokes
  the following error in audio_alsa_sink:

audio_alsa_sink[plughw:0,0]: snd_pcm_hw_params failed: File descriptor
in bad state
terminate called after throwing an instance of 'std::runtime_error'
  what():  check topology failed on audio_alsa_sink(1) using ninputs=1,
noutputs


Am I being an idiot here?  Should this work?  If not, why not?

Further, there's a "OK to block" parameter for an audio_alsa_sink.  What
does it do?


-- 
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


 
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Can USRP2 connect to Beagle Board-Xm?

[Almohanad Fayez]

Unfortunately that doesn't work, I tried doing that with a TI board, DM6446, it 
had 100M Ether and I used a GigE switch so I ended up using a regular USRP.  
You can detect the USRP2 using the provided script but you won't be able to 
receive radio samples.  If memory serves correctly, there are some GigE 
specific throtteling packets that the USRP2 sends out that 100M Ethernet can't 
understand.


al






-Original Message-
From: Josh Blum 
To: discuss-gnuradio@gnu.org
Sent: Wed, Oct 13, 2010 12:06 pm
Subject: Re: [Discuss-gnuradio] Can USRP2 connect to Beagle Board-Xm?


I head that you can use a gigE switch between usrp2 and 100M Ethernet. Then it 
may work. -Josh 
 
On 10/13/2010 07:35 AM, Zhen wrote: 
> Hello, 
> 
> I want to know if GNU Radio USRP2 can connect to Beagle Board- Xm 
> 
> I know Beagle-board can connect to USRP by USB connection. Now BeagleBoard-XM 
> has 100M Ethernet, and USPP2 uses 1000M Ethernet, can they work together? 
> 
> Thanks 
> 
> Zhen 
> 
> 
> 
> 
> 
> 
> 
> ___ 
> Discuss-gnuradio mailing list 
> Discuss-gnuradio@gnu.org 
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio 
 
___ 
Discuss-gnuradio mailing list 
Discuss-gnuradio@gnu.org 
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio 

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gnuradio on beagleboard?

[Almohanad Fayez]

 If you're interested in taking the DSP approach on the Beagleboard my favorite 
guide to setting up and installing the proper environment is

http://ossie.wireless.vt.edu/trac/wiki/BeagleBoard

I've heard that the steps are a little outdated but if you stick with the 
toolset versions indicated on the webpage you should be fine.  I've managed to 
target the DSP from GNU Radio to do filtering mostly. I plan on making my code 
available but I've been too busy lately trying to meet some project deadlines 
so it might take me a while to do so.

But basically you can connect to the DSP from GNU Radio if tell the TI tools to 
generate libraries instead of excutable for your application and then you can 
follow the "How to write a Custom GNU Radio" tutorials to add them as custom 
blocks.

 


 

 al fayez


-Original Message-
From: Philip Balister 
To: Thunder87 
Cc: Discuss-gnuradio@gnu.org
Sent: Mon, Sep 6, 2010 3:44 pm
Subject: Re: [Discuss-gnuradio] gnuradio on beagleboard?


On 09/06/2010 03:06 PM, Thunder87 wrote: 
> 
> Am I correct, thinking that gnuradio should work on any platform, as long as 
> it's on ubuntu? 
 
GNU Radio will run on Linux, OSX, and possibly windows etc. As noted, Ubuntu is 
just one flavour of Linux 
 
> 
> Will I be able to run it on  http://beagleboard.org/ Beagleboard  with 
> http://elinux.org/BeagleBoardUbuntu Ubuntu ? 
 
GNU Radio runs on the Beagleboard already. Only the FIR fff filter has been 
optimized for NEON SIMD though. 
 
There are some guys at Virginia Tech looking at the using the DSP with GNU 
Radio also. They might have some more suggestions. 
 
Philip 
 
___ 
Discuss-gnuradio mailing list 
Discuss-gnuradio@gnu.org 
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio 

 
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio