Hi everyone,
I have been selected for GSoC 2014 under GNU Radio. I will be working
on VOLK over the summer - my project proposal and GSoC page are as
follows :
1. https://github.com/abhowmick22/GSoc14-Proposal/blob/master/gsoc-proposal.pdf
2.
Hello,
I'm getting the following error when trying to run a gnuradio graph with
USRP in windows:
File c:\Program
Files\gnuradio\lib\site-packages\gnuradio\uhd\uhd_swig.py, line 22, in
swig_import_helper
_mod = imp.load_module('_uhd_swig', fp, pathname, description)
ImportError: DLL load
Backing off to Ubuntu 12.04.4 LTS was successful in getting the PCIe
Express interface to build, dkms the kernel module, start and
uhd_find_device sees the USRP x300.
Now for the fun part using it.
Finally:
To all those entertaining PCIe interfacing, do not install a later version
of
On 04/27/2014 02:45 PM, Robert McGwier wrote:
Backing off to Ubuntu 12.04.4 LTS was successful in getting the PCIe
Express interface to build, dkms the kernel module, start and
uhd_find_device sees the USRP x300.
Now for the fun part using it.
Finally:
To all those entertaining PCIe
While the top side API is
very stable so that applications hardly *ever* experience API changes
that require on-going tedious maintenance, the same cannot be said of code
that runs in the kernel. Quite the contrary. Linus and friends
*routinely and regularly* change critical APIs within
On 04/27/2014 05:32 PM, Sylvain Munaut wrote:
While the top side API is
very stable so that applications hardly *ever* experience API changes
that require on-going tedious maintenance, the same cannot be said of code
that runs in the kernel. Quite the contrary. Linus and friends
Hi,
So, would we accept an applications-layer API that changed roughly every two
months? I would argue, no, we wouldn't. But
people developing in kernel land seem to accept it as some kind of
necessary gospel.
For the kernel, the application layer API is the user space
interface and
Hello all,
I'm hoping someone can provide some insight to a build problem I'm seeing.
I'm building 3.3.0 to use with an Ettus Research USRP1.
I'm given to understand that I need to build 3.3.0 as that was the last release
which is compatible with the usrp1.
I've gone through the dependencies
On 04/27/2014 06:56 PM, Michael Carter wrote:
Hello all,
I'm hoping someone can provide some insight to a build problem I'm seeing.
I'm building 3.3.0 to use with an Ettus Research USRP1.
I'm given to understand that I need to build 3.3.0 as that was the last release
which is compatible with
I am trying to compile the lasted code from github and am getting an error
from CMake. It is looking for pyZMQ and not finding it. I tried to install
the module but not having much luck - that is it is not simple. Is there a
scenario that I can follow? The dependency list does not cite PyMZQ
I have a question about handling data after binary slicing in the
demodulation portion of handling a signal. Currently I am taking that data
and pushing it through the Correlate Access Code block then into a file
sink. This produces a data file. I didn't know if someone could tell me a
block or
Thanks Marcus.
This is for OpenBTS 2.8, which based on the myriad lists I've been researching,
is a pre-UHD application.
Anyone have any insight the issue?
Thanks,
#mikec
On Apr 27, 2014, at 4:00 PM, Marcus D. Leech mle...@ripnet.com wrote:
On 04/27/2014 06:56 PM, Michael Carter wrote:
On 04/27/2014 10:14 PM, Michael Carter wrote:
Thanks Marcus.
This is for OpenBTS 2.8, which based on the myriad lists I've been
researching, is a pre-UHD application.
Anyone have any insight the issue?
Thanks,
#mikec
OpenBTS doesn't actually use Gnu Radio, just some of the driver code for
Hi-
Comments Interspirsed
On Wed, Apr 16, 2014 at 4:22 AM, Gayathri Ramasubramanian
grama...@vt.eduwrote:
Hi
My project is dealing with Tx/Rx Characterization. I wanted to know if
anyone has tried finding the IIP3 and OIP3 for the USRP N210 with WBX and
SBX daughter-boards.
I did an
Hi Marcus.
Thanks, yes that seems to be bearing itself out so far.
I'm fairly certain that if I can get the code that came along for the ride
installed, then I'll be set.
So the issue is still why the makefiles don't detect usb.h and libusb even
though they're installed.
Is there a trick I
On 04/27/2014 10:31 PM, Michael Carter wrote:
Hi Marcus.
Thanks, yes that seems to be bearing itself out so far.
I'm fairly certain that if I can get the code that came along for the
ride installed, then I'll be set.
So the issue is still why the makefiles don't detect usb.h and libusb
even
mkfifo my_fifo.bin
hexdump my_fifo.bin
Point your file sink to the my_fifo.bin and turn off the buffering. It will
then dump the data to the terminal in real time.
Lou
KD4HSO
Jay Radcliffe wrote
I have a question about handling data after binary slicing in the
demodulation portion of
Jay,
Thanks for the inquiry. Is there a specific protocol or format you are
trying to work with? Are the frame size fixed in length or variable? The
answers to these questions will dictate whether you can use an existing
block or if you will need to write your own.
Writing a block to parse
I do not know if the previous mail sent sucessfully or not. so reply again.
Sorry about that.
provide amplifier, LNA, duplexer
Regards
On Mon, Apr 28, 2014 at 10:48 AM, John Wu jwjo...@gmail.com wrote:
Hi list,
If anyone needs amplifier, LNA, duplexer please contact me. I can make any
kind
19 matches
Mail list logo
