On Fri, Jun 6, 2008 at 4:02 AM, Naoufel Amri <[EMAIL PROTECTED]> wrote:
> Do you know if the receiver function of "usrp_radar_mono.py" is complete?
> If yes,where are the datas ,which are recovered by the receiver, store ? And
> how can I get them back?
The gr-radar-mono transceiver records, duri
Thanks for the quick reply. Please see inline responses.
>
>
> Date: Fri, 06 Jun 2008 12:19:56 -0400
> From: Greg Troxel <[EMAIL PROTECTED]>
> Subject: Re: [Discuss-gnuradio] 802.11 on USRP+GNURadio
> To: "sri ram" <[EMAIL PROTECTED]>
> Cc: discuss-gnuradio@gnu.org
> Message-ID: <[EMAIL PROTECTED
It is defintely do-able in real time software. I have done some work in the
past that continuosly decoded all 8 timeslots in real time on a 1GHz PPC.
Also, the processor usage goes way down when you only look at 1 of the 8
timeslots, which is usually all that is needed.
Ben
On 6/6/08, Long, Jeff
Bob McGwier wrote:
The USRP is not in the same league with the USRP2. The on board
oscillator is much better but external oscillators will make it even
better. So the answer is a big yes, the USRP2 will be better.
Actually, I need to disagree again here :)
The master oscillator on the USRP1
Matt Ettus wrote:
Jeff Brower wrote:
Bob-
In your sixteen QAM and other figures I see two effects.
Notice just the slightest hint that arcs through the top four
constellation points in the 16 QAM is not straight. This curvature is
caused by nonlinearity.
Your result almost surely can NOT
Bob-
> Good to hear from you again. I am distinguishing betwen clock recovery
> operations in the receiver and the oscillator feeding the down
> conversion mixers. Even though there is some commonality in the sources
> for these two DIFFERENT things on the USRP, implementation factors of
> the
Jeff:
Good to hear from you again. I am distinguishing betwen clock recovery
operations in the receiver and the oscillator feeding the down
conversion mixers. Even though there is some commonality in the sources
for these two DIFFERENT things on the USRP, implementation factors of
the clo
The USRP is not in the same league with the USRP2. The on board
oscillator is much better but external oscillators will make it even
better. So the answer is a big yes, the USRP2 will be better.
Bob
Per Zetterberg wrote:
-Original Message-
From: Bob McGwier [mailto:[EMAIL PRO
Jeff Brower wrote:
Bob-
In your sixteen QAM and other figures I see two effects.
Notice just the slightest hint that arcs through the top four
constellation points in the 16 QAM is not straight. This curvature is
caused by nonlinearity.
Your result almost surely can NOT be clock jitter.
Bob McGwier wrote:
There is insufficient dynamic range in any GPS signal on any ordinary
mortals GPS antenna to use more than 8 bits.
Not so if the signal is being jammed...
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu
We've had similar issues. Please see our 802.11 receiver implementation:
http://span.ece.utah.edu/pmwiki/pmwiki.php?n=Main.80211bReceiver
Indeed - you should definitely try the others. Ours sort of works, and
has a c ool hack to fit within USRP USB bus bandwidth, but I expect
implementatio
Steve-
You know what, you might be right here. I am starting to remember that
it could be BT dependent. My application called out for a BT of .5
which is not too severe(we didn't really have ACI issues) so in reality
the threshold might be good enough right thru the center. With
something more sev
Sri Ram,
We've had similar issues. Please see our 802.11 receiver implementation:
http://span.ece.utah.edu/pmwiki/pmwiki.php?n=Main.80211bReceiver
Regards,
Neal
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailm
On Fri, Jun 06, 2008 at 08:35:41AM -0700, irene159 wrote:
>
>
> In my case, it works replacing "from gnuradio import blks2" by "from
> gnuradio.blks2impl import rational_resampler" but that doesn't explain why
> command line works from the terminal but not from the file...
>
> irene159 wrote:
>
On Fri, Jun 6, 2008 at 9:30 AM, Long, Jeffrey P. <[EMAIL PROTECTED]> wrote:
> Steven-
>
> Did you actually find that the decision threshold needs to be biased? I
> actually implemented the 2 bit differential detector on a custom asic
> that was targeted at streaming audio(in 2004) and during the
>
Looking at the archives, I understand that I can receive 1 Mbps
probe/beacon packets with code developed by BBN. I use their code and
see packets at 1 Mbps from different nodes.
However, I don't know of a way to have the USRP as a destination for a
flow using standard packet generation to
On Fri, Jun 6, 2008 at 8:56 AM, isaacgerg <[EMAIL PROTECTED]> wrote:
>
> Ive noticed that the papers you cited only take in "real" data and not
> "complex." Is this true? Is this true for your implementation?
>
> Isaac
I think they do in fact take in complex. How would one do a 90deg
phase shift
Sorry.
The subject of my previous mail ought to have been 802.11 on USRP.
Sriram
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Hello all,
I am trying to use the USRP to capture 802.11 packets and
have a few questions.
Looking at the archives, I understand that I can receive 1 Mbps
probe/beacon packets with code developed by BBN. I use their code and
see packets at 1 Mbps from different nodes.
However, I don't k
In my case, it works replacing "from gnuradio import blks2" by "from
gnuradio.blks2impl import rational_resampler" but that doesn't explain why
command line works from the terminal but not from the file...
irene159 wrote:
>
> Hello,
>
> Concerning blks2 import (blks2.rational_resampler need
I agree with Steven, while there are definitely more "optimal"
solutions like MLSE they don't always make sense for every application.
GSM phones and the like have dedicated DSP resources to run a Viterbi
algorithm but is this doable on the typical gnu users computer? I will
defer to the experts on
> On 6/6/08, Bob McGwier <[EMAIL PROTECTED]> wrote:
>>
>> This is not my professional experience. The sounding data is used to find
>> the channel and then the data symbols are soft detected through a "viterbi
>> equalizer" in every implementation I am aware of that is any good at all
>> with the
I agree with Bob, most gsm demodulators I have seen use a viterbi equalizer
(sometimes called MLSE equalization).
Ben
On 6/6/08, Bob McGwier <[EMAIL PROTECTED]> wrote:
>
> This is not my professional experience. The sounding data is used to find
> the channel and then the data symbols are soft
Bob-
> In your sixteen QAM and other figures I see two effects.
>
> Notice just the slightest hint that arcs through the top four
> constellation points in the 16 QAM is not straight. This curvature is
> caused by nonlinearity.
>
> Your result almost surely can NOT be clock jitter. If you had
Steven-
Did you actually find that the decision threshold needs to be biased? I
actually implemented the 2 bit differential detector on a custom asic
that was targeted at streaming audio(in 2004) and during the
simulations I found that moving the bias point did very little for
performance. Maybe i
Ive noticed that the papers you cited only take in "real" data and not
"complex." Is this true? Is this true for your implementation?
Isaac
Steven Clark-2 wrote:
>
> I've added a link to
> http://gnuradio.org/trac/wiki/Enhanced_GMSK_Demodulator from
> http://gnuradio.org/trac/wiki/OurUsers
Hello everybody,
Do you know if the receiver function of "usrp_radar_mono.py"
is complete?
If yes,where are the datas ,which are recovered by
the receiver, store ? And how can I get them back?
Thanks a lot!
Naoufel
Hello,
Concerning blks2 import (blks2.rational_resampler needed)
"from gnuradio import blks2" works on python command line but not in python
file (ImportError: cannot import name blks2).
Where can this come from?
Regards,
Irene
--
View this message in context:
http://www.nabble.com/Import-
> -Original Message-
> From: Bob McGwier [mailto:[EMAIL PROTECTED]
> Sent: den 6 juni 2008 09:23
> To: Per Zetterberg
> Cc: discuss-gnuradio@gnu.org; 'Per Zetterberg'
> Subject: Re: [Discuss-gnuradio] OFDM results.
>
> In your sixteen QAM and other figures I see two effects.
>
> Notic
There is insufficient dynamic range in any GPS signal on any ordinary
mortals GPS antenna to use more than 8 bits.
Bob
Chris Stankevitz wrote:
Dan Halperin wrote:
USRP's cfile utility cannot write my data without overruns, so I use
my own app which I have attached to this email in case anyon
This is not my professional experience. The sounding data is used to
find the channel and then the data symbols are soft detected through a
"viterbi equalizer" in every implementation I am aware of that is any
good at all with the exception of one I wrote several years ago which
estimates the
In your sixteen QAM and other figures I see two effects.
Notice just the slightest hint that arcs through the top four
constellation points in the 16 QAM is not straight. This curvature is
caused by nonlinearity.
Your result almost surely can NOT be clock jitter. If you had a lot of
clock
32 matches
Mail list logo
