Hi!
We have encountered the same phenomena. The spikes at the carrier frequency
seems to be especially large on the RFX400, but is also there on the RFX2400.
We haven't been able to get rid of it, it's always there when transmitting. We
think it might be an LO-effect.
Regards
//Ulrika and Patri
Take a look at this guide:
http://gnuradio.org/trac/wiki/GNURadioCompanion#CreatingtheXMLBlockDefinition
http://gnuradio.org/trac/wiki/GNURadioCompanion#InstallingtheXMLBlockDefinition
1) create the xml file
2) copy it into ~/.grc_gnuradio/
3) run grc
-Josh
manmah...@yahoo.fr wrote:
I ask how
I ask how can i add a block in grc witch exist in gnuradio for example the
cyclic prefix exist in gnuradio but in grc it's combined in OFDM block and i
want to use it as a block in grc , i know only that i have to configure an xml
file of this block and rebuild gnuradio ( i'm using gnuradio 3.
I ask how can i add a block in grc witch exist in gnuradio for example the
cyclic prefix exist in gnuradio but in grc it's combined in OFDM block and i
want to use it as a block in grc , i know only that i have to configure an xml
file of this block and rebuild gnuradio ( i'm using gnuradio 3.2
Ah OK. Just wondering for my own purposes. I've never really dealt with
ADC/DACs hands on before. They were always magical black boxes in my
undergrad DSP/Comm theory coursework. =) Should of taken a VLSI course or
something.
I will be able to meet my needs with upsample/downsample + filtering.
has anybody else experienced this problem? I am working on receiving an
RF signal, performing processing on the data, and then retransmitting
it, using a pair of RFX400s. On the TX side, I always get this big
carrier spike, even with no input to the RX side. Ive tried just
straight feeding t
cool, I got it working, thanks for the explanation!
--
Posted via http://www.ruby-forum.com/.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
I have : my block is closely based on the howto example. It compiles fine on
the x86 machine as well. I'm starting to point the finger at the gnuradio
installation. It seems that in the
/usr/lib/python2.6/site-packages/gnuradio/gr folder, the
gnuradio_swig_py_runtime.py is the culprit. Is it a file
Colby Boyer wrote:
Say from 100MHz to 88MHz?
You would need to change out the oscillator. There are pin compatible
ones with some other frequencies like 80 MHz, 122.88, and some others.
There is no 88 MHz one, but you could get a custom one from the
manufacturer if you needed. That's an od
Just getting started with GNU radio and I'm trying to compile the source
code with the instructions on the wiki for Ubuntu (8.10 Intrepid). I got the
code from the SVN and bootstrap runs fine, configure will not build the
following (which I assume is ok ) gcell, gr-gcell, gr-audio-jack,
gr-audio-os
On Wed, Jun 24, 2009 at 12:10:29PM -0400, Mark Porter wrote:
> Hi all,
>
> I have compiled a custom block for GNURadio, and it is not running properly.
> My error message below seems to indicate a problem with swig or something
> similar.
Did you define an out-of-line virtual destructor for your
One other change I made in that branch, that other people may be interested
in: I now build a C++-only accessible library, so people building gnuradio
apps just in C++ can access the BBN blocks. I've followed the gnuradio
naming convention and call it libgnuradio-bbn. I think that it's
appropriate
On Wed, Jun 24, 2009 at 1:44 PM, Phillip Walsh wrote:
> I feel fairly comfortable trying that. As far as space on the FPGA goes, I
> remember seeing something in the Mail list archive about disabling/removing
> logic for Side B to make room. If possible, it would work fine in my case as
> I hav
> For using the 3.2 release with the BBN code, you can use my branch on
> CGRAN:
> https://www.cgran.org/browser/projects/bbn_80211/branches/douggeiger
Thanks Doug. I will try to get it running today on 3.2.
> I have no idea if there's enough room left
> on the FPGA to implement that, but if y
For transmitting standards-compliant 802.11b frames from the USRP1 you
really are constrained by the USB link. I don't know if anyone has tried to
implement doing the transmit-side spreading in the USRP1's FPGA, but that is
likely the only way you'll get it to transmit anything commercial 802.11
r
This question is relating to the USRP2. I apologize for leaving that detail
out.
On Wed, Jun 24, 2009 at 6:33 AM, Colby Boyer wrote:
> Thats cute.
>
> I am serious though.
>
> On 6/24/09, Daniel O'Connor wrote:
> > On Wed, 24 Jun 2009, Colby Boyer wrote:
> >> Say from 100MHz to 88MHz?
> >
> >
Hi all,
I have compiled a custom block for GNURadio, and it is not running properly.
My error message below seems to indicate a problem with swig or something
similar.
self.usrp is the usrp source, self.minmax is the custom block
###
File "script.py", line 76, in
tb = my_top_block()
File "scri
Hi all,
I am working on a project where I am trying to have the USRP1 transmit and
receive 802.11 management and control frames to/from commercial 802.11b
hardware. I have the receive functionality working fine using BBN 802.11and
the SPAN receiver on GNU Radio 3.1.1. I see there is a lot of
Thats cute.
I am serious though.
On 6/24/09, Daniel O'Connor wrote:
> On Wed, 24 Jun 2009, Colby Boyer wrote:
>> Say from 100MHz to 88MHz?
>
> Have you purchased a flux capacitor from Ebay?
>
> :)
>
> --
> Daniel O'Connor software and network engineer
> for Genesis Software - http://www.gsoft.co
Hi
I am having alot of problems building CUDA with the current CUDA-enable
GUNRadio branch. I am using Fedora 10.
I followed the
http://www.smallwhitecube.com/php/dokuwiki/doku.php?id=howto:gnuradio-with-cudawiki
and everything is fine up until trying to 'make' gpgpu-wip
I understand that we may
On Tue, Jun 23, 2009 at 04:49:10PM -0700, Brook Lin wrote:
> I'm trying to transmit a wave file using gr.wavfile_source(). To test my
> transmission path, I first transmit a sine wave, and I can receive it and
> sink it to sound card fine. I can hear the sound at the receiver side.
> However, if I
21 matches
Mail list logo