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 a
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
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 runti
re 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
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
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
a
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/1
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
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 provi
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
__
ncies
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:
, 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
sa
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
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:
>
&g
n, 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 gnura
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 s
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 Discus
emory 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
hrough 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
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
, 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
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
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
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, s
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/a
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 bo
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
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
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
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&#x
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 so
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, Almoha
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
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
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 bas
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
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 G
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_regis
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 Beagle
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 mak
ood 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 w
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 flowg
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
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 s
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 o
45 matches
Mail list logo
