On 12.08.2010 00:10, Jason Abele wrote:
> Testing the id number of your DBSRX on USRP2:
Thanks Jason, your diagnosis instructions are very clear now.
I thought it was more than just changing an ID number.
Can you add this to the official mod.-instructions on the gnuradio Wiki?
It would help people
On 11.08.2010 23:11, Marcus D. Leech wrote:
> In Linux, I/O to "disk-like devices" uses write-behind caching. Which
> means that although your application has sent the data to the
> kernel, and it has been accepted, it may not actually get written out
> to disk. This improves performance in man
I'm new for gnuradio and usrp but I tried to use two of them for the
digital beacon receiver. So i tried to understand most of the block
diagram in usrp
and now i have detail of the usrp from many site.
One is the USRP user's and Developer 's Guide(Matt Ettus) and The USRP
under 1.5X Magnifyi
On Wed, Aug 11, 2010 at 11:37 AM, Moeller wrote:
> Call "usrp2_probe" to check if the board ID is 13 now. If it is still 2, the
> burning had no effect.
Moeller has a very good tip here, we use different daughterboard id's
to let the software know if the resistor modification has been
performed.
>
> Call "usrp2_probe" to check if the board ID is 13 now. If it is still 2, the
> burning had no effect.
> I tried two times without success (didn't know that the ID would have to
> change).
> After another 3rd attempt later, I was successful.
> Very strange. Every time I followed the instructio
--- On Wed, 8/11/10, Thomas Tsou wrote:
> From: Thomas Tsou
> Subject: Re: [Discuss-gnuradio] usrp usb problem with Mandriva 2010.1
> To: emat...@yahoo.com
> Cc: discuss-gnuradio@gnu.org
> Date: Wednesday, August 11, 2010, 1:52 PM
> On Wed, Aug 11, 2010 at 11:07
> AM,
> wrote:
> > Hello-
> >
>
On Wed, Aug 11, 2010 at 04:56:10PM +0200, Patrick Strasser wrote:
> Hello!
>
> FYI:
> Just found an article at a German computer news site (Golem)[1]
> about a paper by Ishtiaq Rouf and Rob Miller from University of
> South Carolina and Rutgers University about Security and Privacy
> Vulnerabiliti
I just plug the wbx to simple antennas, matched to the frequency you want
to transmit/receive.
And as Matt said, do not blow your board, don't connect tx to rx.
> On 08/11/2010 10:55 AM, Mark Hemmerlein wrote:
>> Hi
>>
>>
>> I now have a USRP2 with a wbx daughter board up and working under Ubuntu
On Tue, Aug 10, 2010 at 10:06:29PM -0400, Tom Rondeau wrote:
> 2010/8/10 Wipat phonsukkarn :
> > Does anybody knows how to power(^) the signal from the signal source block
> > or USRP source
> > for example signal from signal source are coswt+jsinwt or Ae^(jwt) and i
> > want to ^2 for the result =
On Wed, Aug 11, 2010 at 11:07 AM, wrote:
> Hello-
>
> I am having a usb/USRP issue under x86_64 Mandriva 2010.1 with gnuradio-3.3.0.
>
> I compiled and installed using the default procedure:
> ./configure
> make
> sudo make install
>
> When I try to use usrp_fft.py, I get many errors (see below).
On 11.08.2010 15:49, spaceyaeon wrote:
> Hello,
>
> I am having a similar problem as mentioned by Moeller in his message. I have
> made the required modifications to be USRP2 + DBSRX. All I see is a noise
> floor when I try usrp2_fft.py. I am inputting 2.165 GHz signal through RF
> In. Is there s
Hello-
I am having a usb/USRP issue under x86_64 Mandriva 2010.1 with gnuradio-3.3.0.
I compiled and installed using the default procedure:
./configure
make
sudo make install
When I try to use usrp_fft.py, I get many errors (see below). The gui pops up,
but no data is displayed:
[mat...@loc
On 08/11/2010 10:55 AM, Mark Hemmerlein wrote:
Hi
I now have a USRP2 with a wbx daughter board up and working under Ubuntu (
usrp2_fft.py ). I would like to perform a transmit / receive loopback test to
verify transmit as well as receive. Is there a program or utitility which
may perform this
Hi
I now have a USRP2 with a wbx daughter board up and working under Ubuntu (
usrp2_fft.py ). I would like to perform a transmit / receive loopback test to
verify transmit as well as receive. Is there a program or utitility which
may perform this function?
gnuradio newbie
mark
__
Did anyone have same error???
(2010/08/05 1:02), YouheiFujii wrote:
> Hi all,
>
> Now I try to make full-duplex program on one USRP1 and 2 daughterboards.
> (daughterboard is RFX400)
>
> I tested benchmark_tx/rx.py(in example/digital).
> For example, I use these command.
> --
> TX-PC $ sudo python
Hi,
for the really scary part, check out this paper:
Experimental Security Analysis of a Modern Automobile -- K. Koscher, A.
Czeskis, F. Roesner, S. Patel, T. Kohno, S. Checkoway, D. McCoy, B. Kantor, D.
Anderson, H. Shacham, S. Savage.
The IEEE Symposium on Security and Privacy, Oakland, CA,
Hello!
FYI:
Just found an article at a German computer news site (Golem)[1] about a
paper by Ishtiaq Rouf and Rob Miller from University of South Carolina
and Rutgers University about Security and Privacy Vulnerabilities of
In-Car Wireless Networks[2].
They used GNU Radio and USRP to record th
Hi,:
I'm a newbie to GNURadio/USRP, I have checked the suggested reading at
http://gnuradio.org/redmine/wiki/gnuradio/SuggestedReading, but there're
a lot of material there, it would probably take a year to go through all
sections even if I just read one book from each section. I wonder if
ev
--- On Wed, 8/11/10, Tom Rondeau wrote:
> If you are using more than 2 samples
> per symbol,
> you are oversampling. That is, you are wasting your radio's
> time and
> power processing more samples than is required. The
That wasn't the point - the specific question concerned the required amount
On Mon, Aug 9, 2010 at 8:46 AM, Bob McGwier wrote:
> I think Tom has finished and checked in the PFB based clock recovery based
> on the work by fred harris last summer-ish. Am I right? If not, if I may be
> off assistance in finishing, I will.
>
> Bob
Yes, the PFB clock recovery and the PFB res
On Wed, Aug 11, 2010 at 9:49 AM, ikjtel wrote:
>> In a word, NEVER. No self respecting communication systems designer would
>> allow
>> that much excess bandwidth on the air or any realistic transmission medium.
>
> To me this doesn't make sense. The spectral bandwidth required is never a
> fun
Hello,
I am having a similar problem as mentioned by Moeller in his message. I have
made the required modifications to be USRP2 + DBSRX. All I see is a noise
floor when I try usrp2_fft.py. I am inputting 2.165 GHz signal through RF
In. Is there something that I am doing wrong? Do I need external
> In a word, NEVER. No self respecting communication systems designer would
> allow
> that much excess bandwidth on the air or any realistic transmission medium.
To me this doesn't make sense. The spectral bandwidth required is never a
function of the
samples per symbol (SPS); it's a function
When running a flow graph with vector sources that are reading a variable, does the vector source get
updated when the variable does? Or is there some other way of accomplishing this?
Thanks for any help
Scott Johnston
___
Discuss-gnuradio mailing l
24 matches
Mail list logo