Thank you for answering but I cannot understand what you mean with The USRP
is not a measurement receiver. If USRP was not a measurement receiver,
which is its utility? Moreover, if it is not a measurement receiver what is
the result memorized in m.data that is the output of
Hi guys,
First of all my apologies for my bad English. I am a Dutch student and for a
internship I use GNURadio.
For test purposes I want to show the hexadecimals values of a stream of chars
realtime (while running).
I don't want to use 'printf' in the c-code of a block because sometimes it
On Thu, May 26, 2011 at 07:55:33AM +, nimsi stouwdam wrote:
Hi guys,
First of all my apologies for my bad English. I am a Dutch student and for a
internship I use GNURadio.
For test purposes I want to show the hexadecimals values of a stream of chars
realtime (while running).
I don't
On Thu, May 26, 2011 at 3:08 AM, Marcus D. Leech mle...@ripnet.com wrote:
On 05/25/2011 09:01 PM, Arturo Rinaldi wrote:
i have an issue regarding the SDCC executable in the building of gnuradio
3.3.0 on Fedora 15. I set up the PATH in my *.bashrc* file as :
*export
Very cool, Patrik, thanks for posting!
Tom
On Wed, May 25, 2011 at 7:10 PM, Patrik Tast pat...@poes-weather.comwrote:
Yep,
Patrik
- Original Message - From: Alexandru Csete oz9...@gmail.com
To: Discuss-gnuradio@gnu.org
Sent: Wednesday, May 25, 2011 19:39
Subject: Re:
Hi,
Thank you for the fast reply. I will try what you suggested.
I will let you know if it worked.
regards
Nimsi
Date: Thu, 26 May 2011 11:12:51 +0200
From: martin.br...@kit.edu
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] How to hexdump in gnuradio realtime
On Thu, May 26,
On either my Ubuntu box or my Fedora box, 2.9.0 fails. I used 2.8.0 and all
is well.
I get it from sdcc sourceforge site and was done in a few minutes.
Bob
On May 26, 2011 6:15 AM, Tom Rondeau trondeau1...@gmail.com wrote:
On Thu, May 26, 2011 at 3:08 AM, Marcus D. Leech mle...@ripnet.com
Il 26/05/2011 13:05, Robert McGwier ha scritto:
On either my Ubuntu box or my Fedora box, 2.9.0 fails. I used 2.8.0
and all is well.
I get it from sdcc sourceforge site and was done in a few minutes.
Bob
On May 26, 2011 6:15 AM, Tom Rondeau trondeau1...@gmail.com
Thank you for answering but I cannot understand what you mean with The USRP
is not a measurement receiver. If USRP was not a measurement receiver,
which is its utility? Moreover, if it is not a measurement receiver what is
the result memorized in m.data that is the output of
On Thu, May 26, 2011 at 12:31 PM, Arturo Rinaldi arty.n...@gmail.comwrote:
Il 26/05/2011 13:05, Robert McGwier ha scritto:
On either my Ubuntu box or my Fedora box, 2.9.0 fails. I used 2.8.0 and
all is well.
I get it from sdcc sourceforge site and was done in a few minutes.
Bob
On May
On 26/05/2011 9:55 AM, Michael Dickens wrote:
It would be great if you could share with the list example code snippets of how
you do the pipes. For example: Where in an online repository one can find such
code.
I think that's what Jeff was getting at: that we are providing IANAL advice
Hey guys,
I have written some example code to learn how to dynamically
reconfigure gnuradio based on events generated by probe blocks and a
watcher thread.
First I thought everything is running very well but later I noticed
that the program hangs if you let it run long enough.
If you uncomment the
There should be another sleep in the reconfigure method to make it working fine.
def reconfigure(self):
self.lock()
self.disconnect(self.h_block_one)
self.connect(self.h_block_two)
sleep(0.0001)
self.unlock()
I am not sure how long we have to sleep in order
Has anyone made a Signal generator that can be synced to the PPS, and
10MHz input?
--
Thank you,
Sam Price
(707) 742-3726
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
I did a project similar to this. Look at this structure
m = parse_msg(tb.msgq.delete_head())
There is a field called data (I think) that contains the magnitude of the
sweep. You record m.data to a file (like a csv, hdf5, or binary file).
Keep in mind that you have to do the equivalent of
Changing the fft size won't change your sensing time that much unless the
machine you're using is really slow or the fft size is outrageous. What fft
sizes are you using?
What will affect your sensing time more is the sampling/decimation rate you
sent, the tune delay, and the dwell delay. Be
USRP1:
- When we have a very simple flowgraph with a USRP1 sink connected to a
signal source and a USRP1 source connected to a WX scope- trying to shut
down the app using the close box causes the USB on the host system to
freeze up requiring a reboot. Yanking USRP power or ctrl+c'ing avoids
this
Thank you for replying.
I have already tried different fft size (256, 128, 32, etc) but as you said it
did not change my sensing time. I also change my decimation but no luck too.
I intend to sense a broad band, say, 20M or 40M. But it seems this script costs
too much time working. Should I
On Thu, 2011-05-26 at 19:29 -0500, Brett L. Trotter wrote:
USRP1:
- When we have a very simple flowgraph with a USRP1 sink connected to a
signal source and a USRP1 source connected to a WX scope- trying to shut
down the app using the close box causes the USB on the host system to
freeze up
Hi all:
When I try to implement some spectrum estimate algorithm encounter a
problem like this hope some one can help me out ,cause I really don't
understand how to design
the window in window.py which I have post below or in the attachment.
please help me figure out the midn(fft_size)
Replying to self- here's another case on the USRP2/UHD-
TX Path: Sig Source - UHD (USRP2) Sink
RX Path: UHD (USRP2) Source - Band Pass Filter - Scope Sink
It seems that any kind of filter, even with appropriate calculation of
the rate coming out of the filter taking into account decimation will
On 05/26/2011 08:06 PM, Nick Foster wrote:
On Thu, 2011-05-26 at 19:29 -0500, Brett L. Trotter wrote:
USRP1:
- When we have a very simple flowgraph with a USRP1 sink connected to a
signal source and a USRP1 source connected to a WX scope- trying to shut
down the app using the close box causes
USRP1:
- When we have a very simple flowgraph with a USRP1 sink connected to a
signal source and a USRP1 source connected to a WX scope- trying to shut
down the app using the close box causes the USB on the host system to
freeze up requiring a reboot. Yanking USRP power or ctrl+c'ing avoids
On 05/26/2011 08:06 PM, Nick Foster wrote:
The alignment I'm talking about wasn't even relative between RX and TX-
it was between branches of the RX path such as the real and imaginary
components of that path when viewed on the scope.
So, you're talking about splitting I/Q for the
By default Gnu Radio now schedules each block in its own CPU thread. So
there could be
differences in instantaneous latencies down each path.
Also- whether a data is processed at the same time in terms of physical
timeslices in the real world isn't so important, but by
25 matches
Mail list logo
