Hi,
I am trying to decode CPM signal according to your email but I have problem
with understanding some things. What I'd like to do is to decode some kind
of I/Q samples according to following scenario:
- decimation of symbol rate N-times
- decoding I/Q symbols according to FSM file and provided
Hi, guys
I have two questions:
- My laptop has AgereET131x chipset but it works perfect on Ubuntu8.10.
Then, wonder why I fail to find USRP2 by the 'find_usrps' command?
(I see the chipset 'bad'
here(http://gnuradio.org/trac/wiki/USRP2GigEReports), but it looks like
that the linux and ET131
The definition of the OS table is different than the one you suggest:
For every state s and for every INPUT SYMBOL i it tells you what the
output symbol index o should be.
The reason a transition t is defined
as the pair (s,i) and not as a succession of states (s,s') is that the
latter case
Michael Dickens wrote:
On Feb 10, 2009, at 11:17 AM, Don Ward wrote:
As far as I can tell, MinGW has no standard aligned-memory
allocation functions. Can we use malloc16.c (in gnuradio-core/.../
general) or something like gcell/lib/runtime/gc_aligned_alloc.cc
instead?
malloc16.c requires
I've noticed that on my F10 system, the version of libusb is old
(0.1.12), whereas libusb-1.xx series have been out for a while.
One of the things mentioned in the notes for libusb-1.0 is improved
performance on bulk transfers. I wonder about
the version of libusb causing us overrun grief,
If you're in a hurry to get it to work, your best bet is to go out and buy a
GigE express card. I doubt that much work is going into looking into specific
incompatible chipsets. I could be wrong.
Tim
---
Timothy R. Newman, Ph.D.
Wireless @ Virginia Tech
So i want to learn how to write a block but it fails to install apparently.
after doing ./bootstrap and then ./configure
make gives the following message:
libtool: Version mismatch error. This is libtool 2.2.6, but the
libtool: definition of this LT_INIT comes from an older release.
libtool:
On Wed, Feb 11, 2009 at 03:45:54PM +0100, Emil Molin wrote:
So i want to learn how to write a block but it fails to install apparently.
after doing ./bootstrap and then ./configure
make gives the following message:
libtool: Version mismatch error. This is libtool 2.2.6, but the
Ed Criscuolo wrote:
Once you have the actual binary bitstream, decoding NRZI is easy.
There's a custom block to do this provided in the GMSK Spacecraft
Groundstation project in CGRAN:
https://www.cgran.org/wiki/Projects
This project would be good for you to study, as it represents
a real-world
On Feb 11, 2009, at 12:15 AM, Jakub Moskal wrote:
unfortunately I do need omniORB and omniORBpy, so I don't want to
uninstall them... The CPATH is not set. Do you think that temporarily
removing it, compiling gnuradio and installing it back on would do the
trick?
Hi Jakob - I'm working on a
Hi Michael,
that would be great. I actually want to use CORBA along with GNU
Radio, so that would be perfect.
Thanks a lot for your help.
Jakub
On Wed, Feb 11, 2009 at 10:39 AM, Michael Dickens m...@alum.mit.edu wrote:
On Feb 11, 2009, at 12:15 AM, Jakub Moskal wrote:
unfortunately I do need
Yc Park wrote:
Hi, guys
I have two questions:
- My laptop has AgereET131x chipset but it works perfect on Ubuntu8.10.
Then, wonder why I fail to find USRP2 by the 'find_usrps' command?
(I see the chipset 'bad'
here(http://gnuradio.org/trac/wiki/USRP2GigEReports), but it looks like
that the
I downloaded it from here:
http://sourceforge.net/projects/et131x
I use dkms to auto compile; here is my dkms.conf:
-
PACKAGE_NAME=et131x
BUILT_MODULE_NAME[0]=$PACKAGE_NAME
DEST_MODULE_LOCATION[0]=/kernel/3rdparty/$PACKAGE_NAME/
Hi!
I am currently observing an odd behavior of usrp_siggen.py.
When I start the program as follows
./usrp_siggen.py -f 2.40G -i 16 --gaussian
there are a lot of underruns (uU). However, for all other signal
generation options except gaussian, it works fine (i.e. const, sine,
uniform). Just
On Wed, Feb 11, 2009 at 07:35:10PM +0100, Dominik Auras wrote:
Hi!
I am currently observing an odd behavior of usrp_siggen.py.
When I start the program as follows
./usrp_siggen.py -f 2.40G -i 16 --gaussian
there are a lot of underruns (uU). However, for all other signal
generation
Well, I now have my first user with a USRP2.
So, what are the gotchas that are going to bite me when supporting USRP2
in code that's used to USRP1?
Setup seems a little different--only 1 TX and 1 RX channel, etc.
Here's my new setup_usrp() function:
def setup_usrp(self):
if
Johnathan Corgan wrote:
One significant change to consider is your sample rate plan--you now
have different ADC and DAC frequencies, so depending on what you're
doing, your integer decimation ratios may need to change.
That's not a problem. I run at various bandwidths, depending on what
Hi!
That won't help. The problem is that the gaussian RNG is really slow.
You'll need to figure out how to make it faster.
I am sorry. This was an example and I hoped that the RNG is fast enough.
Actually, I have observed this behavior with my transmitter. As I
described, it doesn't send
On Wed, Feb 11, 2009 at 11:25 AM, Marcus D. Leech mle...@ripnet.com wrote:
The floating point source for the usrp1 has a range of [-32768.0
32767.0], while for the usrp2 it is automatically scaled to [-1.0
1.0]. This will affect your front end range scaling or software AGCs.
Oh. Is that
Here's a screen shot of FFT output:
http://i394.photobucket.com/albums/pp28/optoeng/2peaks.jpg
The image is typical, in that there are multiple narrow local maxima, but
the amplitude of these particular peaks is quite a bit higher than I expect
'in the field'. I'm trying to work out an efficient
On Wed, Feb 11, 2009 at 08:35:56PM +0100, Dominik Auras wrote:
Hi!
That won't help. The problem is that the gaussian RNG is really slow.
You'll need to figure out how to make it faster.
I am sorry. This was an example and I hoped that the RNG is fast enough.
Actually, I have observed
Hi everyone:
I have two questions:
1- I have one RFX1800 Transceiver daughterboard. so can I used benchmark_tx .py
and benchmark_rx.py by using this daughterboard.because from documentation I
read that it is full duplexx but with some limitation.
2- Can I use signal generator to produce AM
Hi!
An additional note: using usrp_siggen.py with sine, const and uniform at
8 MHz bandwidth actually works. It is unlikely that my EHCI controller
does not support 32 MB/s on transmit.
Could this be a timing problem? I mean, that the data is generated very
fast, but then the generator
Hi All,
I am using ./benchmark_tx.py -f 2.4G to send some bytes from my own input
file, and using ./usrp_rx_cfile -f 2.4G to receive the downconverted complex
baseband samples. The modulation I am using on the sender side is dbpsk.
Then, I use
read_complex_binary.m to read the samples into the
Paul Mathews schrieb:
Here's a screen shot of FFT output:
http://i394.photobucket.com/albums/pp28/optoeng/2peaks.jpg
The image is typical, in that there are multiple narrow local maxima, but
the amplitude of these particular peaks is quite a bit higher than I expect
'in the field'. I'm trying
On Wed, Feb 11, 2009 at 10:26:25PM +0100, Dominik Auras wrote:
Hi!
An additional note: using usrp_siggen.py with sine, const and uniform at
8 MHz bandwidth actually works. It is unlikely that my EHCI controller
does not support 32 MB/s on transmit.
OK.
Could this be a timing problem? I
On Wed, Feb 11, 2009 at 6:03 PM, Eric Blossom e...@comsec.com wrote:
Are you really trying to use the Gaussian PRNG? If so you'll have to
fix it. If you look at the code for it, you'll see that it samples a
distribution until it gets something it likes.
A classical reference for fast
On Wed, Feb 11, 2009 at 06:28:16PM -0500, Frank Brickle wrote:
A classical reference for fast generation of random numbers under various
distributions is
Lorrain, D. 1980. *A Panoply of Stochastic 'Cannons'.* Computer Music
Journal 4(1)
The common shortcut to Gaussian random sequences
OK, we got the driver to compile, and spent some time trying to get the
card to talk to the USRP2. If you try enough times, it sort of runs,
but with a lot of noise. It has the same behavior when running through
an ethernet switch. It turns out that the card and/or driver has some
weird
Signal has nothing to do with TV.
Paul Mathews schrieb:
Here's a screen shot of FFT output:
http://i394.photobucket.com/albums/pp28/optoeng/2peaks.jpg
The image is typical, in that there are multiple narrow local maxima,
but the amplitude of these particular peaks is quite a bit higher
Juha Vierinen wrote:
usrp_standard_rx* rx = usrp_standard_rx::make(UsrpNumber,
DecimRate,2,-1,0,4096,4096);
Using gnuradio 3.1.3 and applying the above change plus the
gr_enable_realtime_scheduling(); change fixed my problem. I should try
just making one of the two changes too to see which
31 matches
Mail list logo
