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 MM loop. To keep the logic simple, I set costas-alpha
Using the old versions of the code, I noticed that
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.
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:
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
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 the
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
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
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,
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:
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
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
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
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
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 + 1
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
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
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
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 500MHz
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
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
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
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
22 matches
Mail list logo
