Hi guys，
Could anybody can help me for these problems？
1、I varied Tx_amplitude from 0.1 to 1 and measured the output with a
spectrum analyzer. But the changes are very little. The output is almost the
same when Tx_amplitude is 0.1 and 1. How can I reduce the transmit power to
a very little value?
By the way the VERT400 144MHz, 400 MHz, and 1200 MHz Tri-band 7-inch
vertical
antenna is used.
On Tue, Jun 29, 2010 at 10:21 PM, An He wrote:
> Hi,
>
> I am sure someone has tried to find out the maximum transmission distance
> using USRP2. For example, I am interested in the maximum transmissio
Hi,
I am sure someone has tried to find out the maximum transmission distance
using USRP2. For example, I am interested in the maximum transmission range
in the following setting:
USRP2 with WBX, 400MHz/900MHz, outdoor, los, static,
benchmark_tx/benchmark_rx with default except tx_gain=25 (maximu
On Tue, Jun 22, 2010 at 11:31 PM, Kyle Zhou wrote:
> I am testing the gr_mpsk_receiver_cc module using the code attached at the
> end.
> It is gnuradio v3.3.1git-11-ge20160b7 on cygwin 1.7.5-1 with gcc 3.4.4.
> When I run the code, the following error pops up:
> ===
> asser
On 06/29/2010 10:35 AM, mehmet kabasakal wrote:
Hi everyone,
I want to synchronize the daughterboard LOs for an application.
I have a Rev 4 USRP board and FLEX1800 daughterboard then i followed
the instructions on
http://gnuradio.org/redmine/wiki/1/USRPClockingNotes . At this page it
is given th
On Tue, Jun 29, 2010 at 02:16:24PM -0400, Marcus D. Leech wrote:
> On 06/29/2010 01:37 PM, Eric Blossom wrote:
> > The place to add some debugging outout would be
> > gr_flat_flowgraph.cc::allocate_buffer. Something like:
> >
> > std::cout << "allocate_buffer " << block
> > << " nite
On 06/29/2010 01:37 PM, Eric Blossom wrote:
> The place to add some debugging outout would be
> gr_flat_flowgraph.cc::allocate_buffer. Something like:
>
> std::cout << "allocate_buffer " << block
> << " nitems " << nitems << " item_size " << item_size <<
> std::endl;
>
>
> For the c
On Tue, Jun 29, 2010 at 9:46 AM, Monica Sit wrote:
>
> Hi,
>
> I am trying to install gnuradio-3.2.2 on Linux Mandriva 2010.0 i586.
> The PC is a 32 bit Intel P4 machine.
> When I run the command './configure', all gnuradio components passed the
> configuration tests except
[snip]
> libtool: li
On Tue, Jun 29, 2010 at 04:46:32PM +, Monica Sit wrote:
> Hi,
>
> I am trying to install gnuradio-3.2.2 on Linux Mandriva 2010.0 i586.
> The PC is a 32 bit Intel P4 machine.
> When I run the command './configure', all gnuradio components passed the
> configuration tests except
>
> usrp2-fi
On Mon, Jun 28, 2010 at 09:14:34PM -0400, Marcus D. Leech wrote:
> Spent some time tracking down a memory allocation issue. The SYSV shm
> allocator was getting errors on
> a request for 1.56GB. Now, it turns out that the segment size used by
> SYSV shm uses a signed 32-bit
> int for the size
Hi everyone,
I want to synchronize the daughterboard LOs for an application.
I have a Rev 4 USRP board and FLEX1800 daughterboard then i followed
the instructions on
http://gnuradio.org/redmine/wiki/1/USRPClockingNotes . At this page it
is given that "Recent boards don't need these mods, only earl
Thankyou for this information. It would be useful to have a catalog of
benchmarked systems for reference purposes. Perhaps a wikipage with
this information could be created?
~Jeffrey Lambert
On 6/28/2010 6:16 PM, Marcus D. Leech wrote:
I took delivery on a server (well, the parts to build a
Hi,
I am trying to install gnuradio-3.2.2 on Linux Mandriva 2010.0 i586.
The PC is a 32 bit Intel P4 machine.
When I run the command './configure', all gnuradio components passed the
configuration tests except
usrp2-firmware
gcell
gr-gcell
gr-audio-windows
gr-audio-osx
When I run the comm
Zohair,
You can check what is in the module like so: python -c "from gnuradio
import usrp2; print dir(usrp2)"
['MC_PROVIDE_CLK_TO_MIMO', 'MC_WE_DONT_LOCK', 'MC_WE_LOCK_TO_MIMO',
'MC_WE_LOCK_TO_SMA', 'SwigPyIterator', 'SwigPyIterator_swigregister',
'_MC_MIMO_CLK_INPUT', '_MC_WE_LOCK', '__adc_ra
in gr_ofdm_frame_acquisition.cc file ,the coarse frequency compensation is
gr_expj(-2*PI*freq_delta*d_cplen/d_fft_length*symbol_count)
.i don't know why ,could somebody give me an explanation or tell me which
peper i can refer to ?
thanks in advance
__
> > Hi,
> >
> > I successfully implemented OFDM with two USRPs with LFRX/LFTX at
> 1-50MHz, connect by cable. Now I tried switching over to higher frequencies
> via
> TVRX/WBX. While I receive a perfectly valid looking spectrum with a good SNR,
> it does not seem to decode at >200MHz.
> > If I inc
On 06/29/2010 05:23 AM, Stefan Bruens wrote:
>
> If your demands are really so high, why aren't you using a 64bit machine. On
> top of the larger memory space, you get more registers and guranteed
> existence
> of SSE (only an issue, if you use prebuilt packages). The last time I used
> GR,
>
I also tried this:
zeroise=usrp2.time_spec_t(0,0)
self.$(id).set_time_at_next_pps(zeroise)
and receive:
Traceback (most recent call last):
File "/media/ZOHAIR/top_block.py", line 66, in
tb = top_block()
File "/media/ZOHAIR/top_block.py", line 35, in __init__
zeroise=usrp2.time_spec_t
Dear all,
I am trying to modify the USRP2 block so that the timer is reset at the
beginning. I added this line to the make tag in the xml file:
self.$(id).set_time_at_next_pps(time_spec_t(0,0))
I receive this error:
Traceback (most recent call last):
File "/media/ZOHAIR/top_block.py", line 6
This is just an educated guess, so anyone, please correct me if I am wrong:
GR tries to hide the fact that even for a ringbuffer, memory space is always
linear. Now lets assume you try to do an fft with overlap, with an fft size as
large as your buffer.
The first time, you memory area might be
20 matches
Mail list logo
