I dont know if this helps. I once ran spectrum_sense.py and also got peak spur
at the first several fft points. I think it might relate to the hardware
communication between PC and USRP at the initial stage.
--
Yang
Sent with Sparrow
On 2011年5月26日星期四 at 下午4:14, Lebowski80 wrote:
>
> Thank you
I dont know if this helps. I once ran spectrum_sense.py and also got peak spur
at the first several fft points. I think it might relate to the hardware
communication between PC and USRP at the initial stage.
--
Yang
Sent with Sparrow
On 2011年5月26日星期四 at 下午4:14, Lebowski80 wrote:
>
> Thank you
Hi Johannes,
I think I have faced a similar problem like yours. I intend to implement a
dynamic spectrum access system: sensing on the rx side and transmit on tx side.
I solved the problem in a dumb way: I start and stop rx and tx block orderly in
a while loop and use some global variables to s
>
> On Mon, May 30, 2011 at 6:26 PM, Brett L. Trotter
> wrote:
>
>> I've seen the error with both fusb tech libusb1 and 0.1 as well as on
>> various desktops and laptops and operating systems from various vendors.
>> For what its worth, our USRPs are low serial number (no software serial,
>> p
On Mon, May 30, 2011 at 6:26 PM, Brett L. Trotter wrote:
> I've seen the error with both fusb tech libusb1 and 0.1 as well as on
> various desktops and laptops and operating systems from various vendors.
> For what its worth, our USRPs are low serial number (no software serial,
> physical serial a
Hi All,
Recently I've been using the MMSE interp filter. I found that when I shift a
signal by a fractional amount of 0 (or anything really), the signal goes way
off! I would expect SOME difference, but not this much...
Some example output.
Mu:0 In:(-1.67869,0.480381) Out:(0.0418351,-0.16734)
M
>
> Hi,
>
> I was running uhd_fft.py on USRP N210 with TVRX2 daughter-board. I get
> mysterious peak at every 100 MHz center frequency i.e. 100MHz, 200
> MHz, even though no antenna is connected. Please help me what is wrong.
>
> Thanks you,
> Rahul
>
Two things:
There is almost always an anoma
On 05/30/2011 08:20 AM, Johannes Schmitz wrote:
>> The error is coming from the kernel. Can you describe your system setup?
>
> We tried to run the code on Ubuntu 10.04, 10.10 and 11.04.
> Every time we get the fusb error :(
> It seems we have to throw away our USRP1's and move to USRP2...
>
L
On 05/30/2011 07:29 PM, Thomas Tsou wrote:
On Mon, May 30, 2011 at 5:20 AM, Johannes Schmitz wrote:
We tried to run the code on Ubuntu 10.04, 10.10 and 11.04.
Every time we get the fusb error :(
It seems we have to throw away our USRP1's and move to USRP2...
I'm not able to reproduce this erro
On Mon, May 30, 2011 at 5:20 AM, Johannes Schmitz wrote:
>
> We tried to run the code on Ubuntu 10.04, 10.10 and 11.04.
> Every time we get the fusb error :(
> It seems we have to throw away our USRP1's and move to USRP2...
I'm not able to reproduce this error with the posted examples. Please
try
I used the following two little programs:
unixdomain.c ==
#include
#include
#include
#include
#include
#include
#include
int
main (void)
{
struct sockaddr_un address;
int socket_fd, nbytes;
char buffer[256];
socket_fd = socket (PF_UNIX, SOCK_DGRAM, 0);
On Sat, May 28, 2011 at 12:11 PM, Brett L. Trotter wrote:
> I just discovered the not well published --with-fusb-tech=libusb1 option
> to configure, hoping to resolve the USRP1 non-uhd crashing issues myself
> and one other person are seeing when the flowgraphs do a lock or stop.
> Unfortunately,
On Mon, May 30, 2011 at 5:05 AM, vanITA1082 wrote:
>
> Dear Tom,
>
> Do you mind sharing your code for usrp n210 ?
>
> I am new on gnuradio and usrp and I am not able to find a python example to
> perform packet transmission.
>
>
> Thank you
>
> Vanessa
>
You can find lots of examples from my gr
On Mon, May 30, 2011 at 18:30, Andre Puschmann
wrote:
> On 05/30/2011 03:55 PM, Marcus D. Leech wrote:
>> On 30/05/2011 9:51 AM, Alexander Chemeris wrote:
>>>
Linux' pipe implementation is known to be quite slow. I would suggest to
use UNIX sockets instead. They should perform much bette
Hello Brett,
please use "Reply All" when answering, or send it only to the
mailinglist. But don't send it only to me.
Of course I inserted unlock somewhere after lock. Also you have to
replace tb.run() with tb.start().
Johannes
2011/5/30 Brett L. Trotter :
> On 05/30/2011 07:13 AM, Johannes Schm
On 05/30/2011 03:55 PM, Marcus D. Leech wrote:
> On 30/05/2011 9:51 AM, Alexander Chemeris wrote:
>>
>>> Linux' pipe implementation is known to be quite slow. I would suggest to
>>> use UNIX sockets instead. They should perform much better in terms of
>>> latency and performance.
>> Good idea.
>>
>
On 30/05/2011 9:51 AM, Alexander Chemeris wrote:
Linux' pipe implementation is known to be quite slow. I would suggest to
use UNIX sockets instead. They should perform much better in terms of
latency and performance.
Good idea.
I'm dubious of such a claim--the core mechanisms between Unix-dom
On Mon, May 30, 2011 at 12:54, Andre Puschmann
wrote:
> On 05/29/2011 10:22 AM, Alexander Chemeris wrote:
>> On Sun, May 29, 2011 at 03:05, Marcus D. Leech wrote:
>>> On 05/28/2011 04:28 PM, Alexander Chemeris wrote:
>
> So, while this method is simple and good for non-realtime
> appl
On 30/05/2011 9:41 AM, Johannes Schmitz wrote:
we did not try it under UHD.
Honestly I don't have any experience with UHD.
But do you want to say that the "traditional API" is not supported anymore?
If yes, what is the best way to get started with UHD?
Johannes
The traditional API is no longer
On Sun, May 29, 2011 at 23:57, Colby Boyer wrote:
> On Sun, May 29, 2011 at 1:22 AM, Alexander Chemeris
> wrote:
>> On Sun, May 29, 2011 at 03:05, Marcus D. Leech wrote:
>>> On 05/28/2011 04:28 PM, Alexander Chemeris wrote:
>
> So, while this method is simple and good for non-realtime
>>
Hello Marcus,
> Have you tried it under UHD?
we did not try it under UHD.
Honestly I don't have any experience with UHD.
But do you want to say that the "traditional API" is not supported anymore?
If yes, what is the best way to get started with UHD?
Johannes
___
On 30/05/2011 8:20 AM, Johannes Schmitz wrote:
The error is coming from the kernel. Can you describe your system setup?
We tried to run the code on Ubuntu 10.04, 10.10 and 11.04.
Every time we get the fusb error :(
It seems we have to throw away our USRP1's and move to USRP2...
Johannes
Have
> The error is coming from the kernel. Can you describe your system setup?
We tried to run the code on Ubuntu 10.04, 10.10 and 11.04.
Every time we get the fusb error :(
It seems we have to throw away our USRP1's and move to USRP2...
Johannes
___
Discu
In your gnuradio generated code you use run() instead of start()
method and you forgot to put unlock().
After changing this it crashes with fusb error.
2011/5/27 Brett L. Trotter :
> Does this crash you?
>
> from gnuradio import eng_notation
> from gnuradio import gr
> from gnuradio.eng_option imp
Dear GNU Radio gurus,
I have sent this before but it might have not reached you guys.
Excuse me some basic questions. Point me to another forum or information
site if this is not the right place...
we are supposed to pre-develop an inductive coupling radio transmission
system somewhere between 10
Hi All
Using USRP N210 with GPSDO :
Is it possible to check GPS lock status ?
I have experience with some unit providing 10MHz, 1 PPS and ntp server,
locked on GPS network. But it needed always some time to acquire the
satellite signal after power up. So there were a status {UNLOCKED | LOCKED}
Ba
I'm trying to do some experiment on freq. band 2.4-2.483 GHz with RFX2400
But I could not get what I expected.
My guess is that 802.11 AP and USRP interfere each other, thus it cannot
work well.
Am I right?
--
Seokseong Jeon (aka Songsong Gee)
___
Dis
Hi Justin,
Good thoughts and suggestions.
We have aloso elborated on the same thought "downlink data sharing from USRP
for learning"
A USRP1 was donated to us for GOES LRIT reception investigation. We hoped that
students world wide would hook on to the project but not even one was (or has
sof
On 05/29/2011 10:22 AM, Alexander Chemeris wrote:
> On Sun, May 29, 2011 at 03:05, Marcus D. Leech wrote:
>> On 05/28/2011 04:28 PM, Alexander Chemeris wrote:
So, while this method is simple and good for non-realtime
applications, it doesn't fit our needs. It may be usable for PHY<-
Dear Tom,
Do you mind sharing your code for usrp n210 ?
I am new on gnuradio and usrp and I am not able to find a python example to
perform packet transmission.
Thank you
Vanessa
Tom Rondeau wrote:
>
> On Mon, Jan 17, 2011 at 2:48 PM, Josh Blum wrote:
>>
>>
>> On 01/17/2011 11:31 AM, Vel
I have question on RFX2200
What frequency range does RFX2200 support?
I mean, I know it supports 2.0-2.4 GHz. but,
For RFX2400, it supports 2.3-2.9 GHz if bypassing is applied, basically
2.4-2.483 GHz is supported without bypassing.
Thus, if I did not take bypassing, what frequency range I can use
31 matches
Mail list logo
