> I think the limitation is on the 8051 end. One 512-byte packet takes
> 8.53 microseconds to cross the USB channel, and the 35.7 MByte/sec
> sustained rate implies the 8051 sets up the next packet in only 5.81
> microseconds. I don't think there is any pipelining at this level.
You're probably
On Fri, Oct 27, 2006 at 04:52:50PM -0700, Matt Ettus wrote:
> Kyle Jamieson wrote:
> > After upgrading to FC6, usrp/host/lib/fusb_linux.cc fails to compile
> > (can't find linux/compiler.h). Turns out for me, that include file
> > isn't needed at all (trivial patch attached). I wonder if I've br
>
> Will an RFX400 pass a 6MHz wide signal? (AD834X mixer)
>
>
Easily
Matt
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
On Fri, 2006-10-27 at 19:47 -0400, Charles Swiger wrote:
> On Fri, 2006-10-27 at 11:11 -0500, Meiners, Jason wrote:
> > Has anyone benchmarked the ATSC encode function? Can this be done in
> > real time? Decode is always harder to do than encode :)
> >
>
> Actually, an HDTV transmitter function
Kyle Jamieson wrote:
> After upgrading to FC6, usrp/host/lib/fusb_linux.cc fails to compile
> (can't find linux/compiler.h). Turns out for me, that include file
> isn't needed at all (trivial patch attached). I wonder if I've broken
> something by removing it, or if other systems need it?
I get
On Fri, 2006-10-27 at 11:11 -0500, Meiners, Jason wrote:
> Has anyone benchmarked the ATSC encode function? Can this be done in
> real time? Decode is always harder to do than encode :)
>
Actually, an HDTV transmitter function might fulfill a niche that
couldn't be easily implemented otherwise.
On Fri, Oct 27, 2006 at 09:23:19PM +0200, De Lima Julian wrote:
> So I tested but I have another question.
> I read that the data through the USB cable (from computer to USRP) are in the
> format I/Q complex. (Dawei Shen tutorial)
>
> My interpolation factor is 512, so the sample rate is 128M/512
Uwe -
On Fri, Oct 27, 2006 at 08:35:22PM +0200, Uwe Bonnes wrote:
> > "ldoolitt" == ldoolitt <[EMAIL PROTECTED]> writes:
> ldoolitt> Hi - I'm bringing up a board http://recycle.lbl.gov/llrf4/
> ldoolitt> with a hardware and software USB stack based on and (for this
> Some hints for yo
So I tested but I have another question.
I read that the data through the USB cable (from computer to USRP) are in the
format I/Q complex. (Dawei Shen tutorial)
My interpolation factor is 512, so the sample rate is 128M/512 = 250kSample/s
I have a data list with 500e3 data. 250e3 are of 1000uV a
> "ldoolitt" == ldoolitt <[EMAIL PROTECTED]> writes:
ldoolitt> Hi - I'm bringing up a board http://recycle.lbl.gov/llrf4/
ldoolitt> with a hardware and software USB stack based on and (for this
...
Some hints for your part list:
- consider the Spartan 3E family versus Spartan3. 3E is
On Fri, Oct 27, 2006 at 04:29:33PM +0200, De Lima Julian wrote:
> Hello,
>
> How can I display the data contained inside a vector_sink on the
> terminal? I am doing some tests now...
>
> Thanks
>
> Julian De Lima
There are many examples of its use in
gnuradio-core/src/python/gnuradio/gr/qa_*.p
On Fri, Oct 27, 2006 at 09:40:06AM -0700, [EMAIL PROTECTED] wrote:
> Hi -
>
> I'm bringing up a board
> http://recycle.lbl.gov/llrf4/
> with a hardware and software USB stack based on and (for this purpose)
> equivalent to the GNU Radio design, and measured its USB data transfer
> capabilities m
>>
> So, there's the other half of my question, about doing the TTL control
> thing on a DBS_RX.
> I know you've answered this in the past, but I can't find it in the
> archives.
>
>
The code in gr-usrp/src/db_*.py has examples of how to control the IO pins.
Matt
Matt Ettus wrote:
Dicke switches have typically used rates in the low hundreds of Hz, with
a 50% duty cycle. My understanding is that is not necessary, and was
only done to make things easier with the electronics of the time. I
think I would switch at a much lower rate, 1 Hz or less, and pro
Matt Ettus wrote:
Dicke switches have typically used rates in the low hundreds of Hz, with
a 50% duty cycle. My understanding is that is not necessary, and was
only done to make things easier with the electronics of the time. I
think I would switch at a much lower rate, 1 Hz or less, and prob
Marcus Leech wrote:
How can I make sure that the chanels are properly synchronized with the
hardware state of the switch?
If you used a double-pole relay (or solid-state equivalent) you could
use the extra pole to signal back to an I/O pin what state the switch
was in. That would allow you
Marcus Leech wrote:
>
> In order to do this, I need to know which samples correspond to "sky"
> and which samples correspond to
> "calibration source" as I'm processing them. One thought I had was to
> synthesize a pair of identical channels,
> one called "Sky" and the other called "Calibration"
Hi -
I'm bringing up a board
http://recycle.lbl.gov/llrf4/
with a hardware and software USB stack based on and (for this purpose)
equivalent to the GNU Radio design, and measured its USB data transfer
capabilities more carefully than I have done before. There is a
distant possibility someone on
Has anyone benchmarked the ATSC encode function? Can this be done in
real time? Decode is always harder to do than encode :)
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Charles Swiger
Sent: Friday, October 27, 2006 10:56 AM
To: Kyle Zhou
Cc: discuss-
On Sat, 2006-10-28 at 01:19 +1000, Kyle Zhou wrote:
> I am quite interested in the ATSC project due to some previous HDTV
> R&D experience.
> I am not quite sure about the current status of this project.
> According to my understanding, ATSC has a very high throughput
> requirement with a symbol ra
I'm starting to think about adding Dicke-switching support into my
gr-radio-astronomy continuum
application.
I (once again) need to understand how to use the auxillary TTL I/O bits
on the DBS_RX daughtercard, for
driving the hardware switching apparatus.
But there's another issue that I'm str
I do have 5 kHz sidebands, and this is verified by the location of the
peaks in the first two fft graphs. It's just the third graph which showed
an aliased signal. Could the filter taps be incorrect?
eric
On Thu, 26 Oct 2006, Matt Ettus wrote:
Eric Hill Matlis wrote:
Hello-
I am attempti
I am quite interested in the ATSC project due to some previous HDTV R&D experience.
I am not quite sure about the current status of this project.
According to my understanding, ATSC has a very high throughput requirement with a symbol rate=10.72M / sec
Considering this high symbol rate and the comp
Oh, and what is this line for:
self.gain_control.set_k(10**(self.gain/10))
I commented it out and didn't notice any change in behavior...
By the way- have you had issues with cpuspeed? Normally on my system the
processor is clocked down from 2.2 GHz to 1 GHz. I have another gnuradio
Thanks Chuck!
That works nicely. Much appreciated.
eric
Eric H. Matlis, Ph.D.
Aerospace & Mechanical Engineering Dept.
120 Hessert Center for Aerospace Research
University of Notre Dame
Notre Dame, IN 46556-5684
Phone: (574) 631-6054
Fax: (574) 631-8355
Hello,
How can I display the data contained inside a vector_sink on the
terminal? I am doing some tests now...
Thanks
Julian De Lima
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of Thomas Schmid
> Sent: Wednesday, October 25, 2006 10:37 AM
> To: Tom Rondeau
> Cc: gnuradio mailing list
> Subject: Re: [Discuss-gnuradio] Up Conversion Weirdness
>
> Hi Tom
>
> On 10/25/06, Tom Ronde
Hi everyone!
This is my first post to this list, so please correct me if I do
something wrong.
I have been watching the GnuRadio project for a while, and I must say
that it is an impressive piece of work. I am currently doing a
pre-study for my master thesis on building software defined GPS
rece
28 matches
Mail list logo