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 c
On Tue, Feb 10, 2009 at 11:44 PM, George Nychis wrote:
>
> But eek, what I meant was:
> https://www.cgran.org/svn/
>
> rather than:
> https://www.cgran.org/cgran/
>
> I don't think I can have the base URL used for both SVN and web.
>
> Still legit?
Definitely.
Frank
--
When small birds sig
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 hav
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
lat
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 th
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, eve
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
4
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: Yo
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-worl
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 br
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 wrote:
> On Feb 11, 2009, at 12:15 AM, Jakub Moskal wrote:
>>
>> unfortunately I do need omniORB and
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 li
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/"
AUTOINS
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
> genera
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 (se
On Wed, Feb 11, 2009 at 11:10 AM, Marcus D. Leech wrote:
> 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.
Yes, it is simpler in this regard, no subdev, etc.
One signifi
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 wh
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 with
On Wed, Feb 11, 2009 at 11:25 AM, Marcus D. Leech 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 done on the
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 obse
Hi!
What kind of an EHCI controller do you have?
We've come across some that won't support 32MB/s on transmit.
http://www.asus.com/products.aspx?modelmenu=1&model=2593&l1=3&l2=179&l3=815&l4=0
Intel X58 chipset on an Asus P6 Deluxe. We are using the onboard controller.
test_usrp_standard_tx r
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 modul
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 waits
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 ma
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 t
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 probl
On Wed, Feb 11, 2009 at 6:03 PM, Eric Blossom 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 generation of ran
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 se
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 so
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 highe
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 o
34 matches
Mail list logo
