On Mar 7, 2007, at 9:53 PM, Jeremy Chew wrote:
Thanks. Here is an update...
So far I have tried all the following together: - Increasing the
cable attenuation value to 50dB - Cutting the receive gain setting
to 0
- Using high-frequency cables
FWIW, I have had success with the Rx PGA ga
Thanks. Here is an update...
So far I have tried all the following together:
- Increasing the cable attenuation value to 50dB
- Cutting the receive gain setting to 0
- Using high-frequency cables
There is no apparent change, so I may have to cut the transmit power.
Jeremy
- Original Me
Gregory W Heckler wrote:
To all concerned parties:
I think I've discovered the problem. My "tune" routine chose the R and
N dividers to minimize the difference between the command and desired
LO frequencies. For L1 this ended up being 64 and 25197. The refclk
was set at 4 MHz, producing an R
Gregory W Heckler wrote:
To all concerned parties:
I think I've discovered the problem. My "tune" routine chose the R and
N dividers to minimize the difference between the command and desired
LO frequencies. For L1 this ended up being 64 and 25197. The refclk
was set at 4 MHz, producing an R
On Mar 7, 2007, at 1:47 PM, Tarun Tiwari wrote:
Hi,
I have written a code for simultaneous TX/RX for RFX2400 as
followed below:
self.rx = usrp.source_c (0,self.decim)
self.tx = usrp.sink_c (0, self.interp)
.
.
.
fg = my_graph()
.
.
.
fg.subdev.set_enable(True) # Enable transmitter
fg.conne
To all concerned parties:
I think I've discovered the problem. My "tune" routine chose the R and N
dividers to minimize the difference between the command and desired LO
frequencies. For L1 this ended up being 64 and 25197. The refclk was set
at 4 MHz, producing an R divider frequency of 62500
I've noticed that the DLL of my software receiver settles to +15 Hz,
and the true IF is +24 kHz from the predicted IF. This would indicate
that the 64 MHz board clock is ~1 kHz from its spec value. This, in
itself is not a problem, but I was wondering if this was within
tolerances of the onbo
On 3/7/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Brian Padalino wrote on Mon, 5 Mar 2007 16:05:09 -0500:
>That Analog Devices AD9235-65 looks like it's good if you want to
>sample at something like the USRP is doing right now - 64MHz. So what
>you'd be looking at is an oscope with a 500M
Brian Padalino wrote on Mon, 5 Mar 2007 16:05:09 -0500:
That Analog Devices AD9235-65 looks like it's good if you want to
sample at something like the USRP is doing right now - 64MHz. So what
you'd be looking at is an oscope with a 500MHz bandwidth and a 64MSPS
sampling rate. You could possibl
Robert McGwier wrote:
There is a multiplier circuit/ PLL in the DBS-RX. Whatever phase
noise is coming from the oscillator is being multiplied considerably
by this upconversion to be used at LO in the DBS-RX. You cannot get
low phase noise oscillators and high performance mixers in that sma
There is a multiplier circuit/ PLL in the DBS-RX. Whatever phase noise
is coming from the oscillator is being multiplied considerably by this
upconversion to be used at LO in the DBS-RX. You cannot get low phase
noise oscillators and high performance mixers in that small a package.
Together
Gregory W Heckler wrote:
I measured the phase noise of the 64 MHz board clock. Looking at the
result, I doubt the board clock is producing the phase noise I am
seeing in my receiver.
Hi,
I have written a code for simultaneous TX/RX for RFX2400 as followed below:
self.rx = usrp.source_c (0,self.decim)
self.tx = usrp.sink_c (0, self.interp)
.
.
.
fg = my_graph()
.
.
.
fg.subdev.set_enable(True) # Enable transmitter
fg.connect(fg.rx, fg.tx)
.
.
.
When I receive and then transm
On Wed, Mar 07, 2007 at 09:59:02AM -0800, Daniel Garcia wrote:
>
> I think I've misunderstood they way GR_SYNC_BLOCK
> works. Can someone set me strait?
>
> I've called set_history(1) in the constructor; I have
> one input and one output. I assumed that the in buffer
> would contain noutput_items
Peter Monta wrote:
Martin Dvh wrote:
Maybe you could inject a stable frequency near the wanted RX frequency.
Say a few Mhz away from the 1.57542e9 you want to receive.
Then you could use this in the output to remove the jitter and LO drift.
for example:
inject 16 Mhz (=25 harmonic of
Marcus Leech wrote:
Robert McGwier wrote:
The wideband engine, Mercury:
http://hpsdr.org/wiki/index.php?title=MERCURY
is almost ready to release and its accompanying transmitter Penelope
will follow shortly. BOTH of these boards will have ANOTHER Cyclone
II on them with almost 100% of the
> 1) That out[i] bothers me. Shouldn't it be out[ii]?
Yes, it should. I edited the snippet in the email to
remove a bunch of std::cout junk.. mucked that up in
the process.
> 2) Is there a good reason for doing this in two
> passes with two stores
> to each memory location?
There is a very go
Daniel Garcia wrote:
work (
int noutput_items,
gr_vector_const_void_star &input_items,
gr_vector_void_star &output_items)
{
const float *in = (const float *) input_items[0];
float *out = (float *) output_items[0];
for (int ii = 0; ii < noutput_i
I think I've misunderstood they way GR_SYNC_BLOCK
works. Can someone set me strait?
I've called set_history(1) in the constructor; I have
one input and one output. I assumed that the in buffer
would contain noutput_items + 1 samples; with in[0]
being the history (overlap) from the previous.
I'm
Tom Rondeau wrote:
-Original Message-
Yes, I'm sure these are related. It has a lot to do with how much the phase
rotates between samples, and the Costas Loop corrects the phase for every
sample; if the SNR is high and you have many samples per symbol, many of
those samples are going to
> -Original Message-
> From: Dan Halperin [mailto:[EMAIL PROTECTED]
> Tom Rondeau wrote:
> > small increase in --costas-alpha. The main issue with these gains is the
> > different samples per symbol, which is corrected for mostly by changes
> in
> > the mu gain in the M&M loop. To keep the
Hi!
> I kicked the can down the road with Matt Ettus and Tom Rondeau. We have
> spent two weeks on this total and others are welcome to contribute. We
> need to have the argument: How do we specify the constellations? How do
> we map carrier usage (which are pilots, clocks, etc.)?
To open a
Hi!
> This is the first odd thing, and I believe the cause of the problem.
> Your source does not block until it receives something.
> Generally speaking, returning 0 is a bad idea.
>
> In the case of sources, you should block until you get something, then
> return whatever you got.
The source re
2007/3/7, Eric Blossom <[EMAIL PROTECTED]>:
Folks, please trim your posts.
Do not top post like I just did (to illustrate what I'm talking
about). For that matter, don't blindly bottom post either.
Note the 5 copied messages.
I've added some notes regarding this to the wiki:
http://gnuradio.or
On Wed, Mar 07, 2007 at 06:17:04AM -0800, Kuntal Majumdar wrote:
> Well, thats good enough. But then, I havent still got the relevant
> documentation on this anywhere on the trac. I mean, I want to know
> how does the host side handle all the related (I)FFT stuff.
It uses the GNU Radio fft block,
Folks, please trim your posts.
Do not top post like I just did (to illustrate what I'm talking
about). For that matter, don't blindly bottom post either.
Note the 5 copied messages.
Thanks,
Eric
On Wed, Mar 07, 2007 at 02:52:18AM -0800, Brett Trotter wrote:
>
> Out of curiosity, what gener
On Wed, Mar 07, 2007 at 11:29:19AM +0100, Dominik Auras wrote:
> Hi!
>
> I am encountering a problem with gr_head. For my testcase, I set up a
> flow graph:
>
> (...)
> tcp_src = qtblocks.tcp_source (gr.sizeof_char, "127.0.0.1", )
> head = gr.head(gr.sizeof_char, 4)
> vector_sink = gr.vector_
Robert McGwier wrote:
The wideband engine, Mercury:
http://hpsdr.org/wiki/index.php?title=MERCURY
is almost ready to release and its accompanying transmitter Penelope
will follow shortly. BOTH of these boards will have ANOTHER Cyclone
II on them with almost 100% of their territory being de
Can you reconfigure the FPGA by changing some software based description
in a development tool (Quartus) or do you need to break out a soldering
iron or SMT rework station?
The facts are: what is run in an FPGA is SOFTWARE DEFINED.
I despise this dichotomy to the n-th degree and aver it is who
Well, thats good enough. But then, I havent still got the relevant
documentation on this anywhere on the trac. I mean, I want to know how does the
host side handle all the related (I)FFT stuff.
Please help me in this regard.
Maybe some USRP documentation on OFDM might suffice.
Thanks a lot.
R
http://www.gnuradio.org/trac/browser/gnuradio/branches/developers/n4hy
is the trac and
svn co http://gnuradio.org/svn/gnuradio/branches/developers/n4hy/ofdm
gets you the source. I am merging the trunk into this about every 50
revisions unless I see major progress on mblock, usrp, etc that
You have not read or internalized the specifications for the oscillator
on the USRP which is intimately involved in this system. It is 50 ppm
accuracy which is bad enough, but look at the can. It is begging to
have thermal variances. Start up the usrp and your process and
investigate Newton
"Brett L. Trotter" <[EMAIL PROTECTED]> wrote: Trond Danielsen wrote:
> I read in an earlier thread that you want to do the (I)FFT processing
> in the FPGA. This is not how it is intended to be used. GNU Radio is a
> software radio framework, and the goal is to move as much of the
> signal proces
Trond Danielsen wrote:
> I read in an earlier thread that you want to do the (I)FFT processing
> in the FPGA. This is not how it is intended to be used. GNU Radio is a
> software radio framework, and the goal is to move as much of the
> signal processing as possible onto the host computer. Moving
Hello,
Who is doing the OFDM project? May I get some info on that, because my thesis
project is on the same and I would love help in this regard.
Thanks a lot.
Regards,
Kuntal
Need Mail bonding?
Go to t
2007/3/7, Kuntal Majumdar <[EMAIL PROTECTED]>:
Recently, Brian told me that the FFT-IFFT processing is handled by the host
side. Can I know how this is done exactly? Is there any relevant
documentation for this on the Wiki?
Did you read this:
http://www.gnu.org/software/gnuradio/doc/exploring-g
What is the current status of the OFDM project? Is it such that I could
give it a try using a tunnel.py type setup over a shared wireline - or
at least over two separate RX/TX wires?
Last I heard the receiver and transmitter were working but not over the air.
Hello,
Recently, Brian told me that the FFT-IFFT processing is handled by the host
side. Can I know how this is done exactly? Is there any relevant documentation
for this on the Wiki?
Thanks a lot.
Regards,
Kuntal
__
Out of curiosity, what generation USRP do you have? My Rev 3 board has quite
a lot of clearance on the TX-B side (1/4"ish- not measured)
Weber, Michael J. (US SSA) wrote:
>
> I have identified the cause of the shorting issue I was experiencing and
> thought I would share. The bottom-left corner
Hi!
I am encountering a problem with gr_head. For my testcase, I set up a
flow graph:
(...)
tcp_src = qtblocks.tcp_source (gr.sizeof_char, "127.0.0.1", )
head = gr.head(gr.sizeof_char, 4)
vector_sink = gr.vector_sink_b()
self.fg.connect (tcp_src, head, vector_sink)
(...)
The logging in the s
Tom Rondeau wrote:
small increase in --costas-alpha. The main issue with these gains is the
different samples per symbol, which is corrected for mostly by changes in
the mu gain in the M&M loop. To keep the logic simple, I set costas-alpha
Using the old versions of the code, I noticed that t
41 matches
Mail list logo
