peak detector can output 1 or 0. What is it outputting?
feldmaus wrote:
Josh Blum joshknows.com> writes:
That says that throttling is not your issue. You are probably correct to
think that the peak detect block stopped outputting samples. -Josh
Is this because i did not configure the Peak-
Josh Blum joshknows.com> writes:
>
> That says that throttling is not your issue. You are probably correct to
> think that the peak detect block stopped outputting samples. -Josh
>
Is this because i did not configure the Peak-Detector correctly,
or because it is a bug ?
Regards Markus
___
On Fri, Apr 17, 2009 at 1:09 AM, William Sherman wrote:
> OK I fixed the error in my Makefile which was giving me the make error.
>
> However I have run into another problem. python doesn't pick up the new
> block when I try to run a python program.
>
> I use,
> from gnuradio import howto
> but th
OK I fixed the error in my Makefile which was giving me the make error.
However I have run into another problem. python doesn't pick up the new
block when I try to run a python program.
I use,
from gnuradio import howto
but the new block is not recognised.
Why would this be?
Do I need to buildi
> Thank you Jason. I will attempt the "good practice"-way first then :)
Not to discourage you from doing things the hard way, but it's really
only necessary if this project is an implementation type of thing. If
all you need is some experimental data for a class project or paper,
then the fast wa
Did you try to define the config path by :
$ export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
before "make" command?
From: Don Latham
To: Discuss-gnuradio@gnu.org
Sent: Thursday, April 16, 2009 2:41:43 PM
Subject: [Discuss-gnuradio] make error
First time w
hii,
I am new to gnu radio, and i successfully done the Fm demodulation. then
i tried to transmit the data. for this i chose the example in
gnuradio-examples/python/digital . transmit.py.
When I executed that example, I got the out put as" >>> gr_fir_fff: using
SSE
On Thu, Apr 16, 2009 at 03:41:43PM -0600, Don Latham wrote:
> First time working with gnuradio. Got through all the installs of support
> stuff apparently OK, but on the make of gnuradio there seems to be a
> problem with benchmark_dotprod_fff in core/src/tests. Shows up later in
> make check with
On Thu, Apr 16, 2009 at 09:05:50PM +, Juha Vierinen wrote:
>
> How about overflows. What is the probability that a USRP2 will drop
> samples guring 24 h of 10 MHz receiving when connected directly to a
> computer? I guess there is no mechanism that guarantees that the data
> is delivered, but
First time working with gnuradio. Got through all the installs of support
stuff apparently OK, but on the make of gnuradio there seems to be a
problem with benchmark_dotprod_fff in core/src/tests. Shows up later in
make check with a flurry of boost::... undefined references. As far as I
can tell th
>> Similar issues exist on the transmit side.
Ok.
> Actually they are quite different. When we assert flow control, we flow
> control _everything_ upstream between the USRP2 and the host. Unless
> you want your network to die, die, die, don't put a switch between
> the USRP2 and the host if you
Johnathan Corgan wrote:
> On Thu, Apr 16, 2009 at 11:51 AM, Marcus D. Leech wrote:
>
> Close. You didn't mention USRP1 or 2, so I'm assuming USRP1, and
> you'll get a baseband signal of a maximum +/-4MHz with decimation of
> 8.
>
Yes, USRP1.
> It's not magic, it's math :-)
>
>
It's so much
Hi all,
Several days ago, I posted a question about using rechargeable batteries
instead of AC adapter for usrp/usrp2. I found a SLA battery (6V 10AH
capacity) might work for our purpose. However, I am not sure if it will
damage the usrp and daughter boards as no working currency is specified
On Thu, Apr 16, 2009 at 08:34:25AM -0700, Johnathan Corgan wrote:
>
> Similar issues exist on the transmit side.
Actually they are quite different. When we assert flow control, we flow
control _everything_ upstream between the USRP2 and the host. Unless
you want your network to die, die, die, d
On Thu, Apr 16, 2009 at 03:13:51PM +, Juha Vierinen wrote:
>
> Off topic: We have been playing around with my USRP2 and it seems very
> nice. I noticed that even though the FAQ strongly discourages
> connecting the USRP2 to your main network, it does actually work. We
> have a fairly large LAN
On Thu, Apr 16, 2009 at 11:51 AM, Marcus D. Leech wrote:
> Ah, fabulous. So if I have a 10.7MHz IF coming out of a receiver in
> real mode, I can just "tune" the BASIC_RX
> to 10.7, and it'll as-if-by-magic become a complex signal of +/-5Mhz?
Close. You didn't mention USRP1 or 2, so I'm assu
On Thu, Apr 16, 2009 at 02:33:56PM -0400, devin kelly wrote:
> So, just to help me understand, let's say that running as root wasn't a
> problem. Like, if you didn't have to be root to open a raw socket.
>
> Would that mean that the open_usrp2_socket() function would just look like
> this
>
> us
Johnathan Corgan wrote:
> On Thu, 2009-04-16 at 14:22 -0400, Marcus D. Leech wrote:
>
>
>> Does the FPGA code for BASIC_RX support a Hilbert transform to convert
>> one of the real inputs into a complex stream?
>>
>
> No, but if your signal of interest has a passband above DC, when you
> "t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Forgot to copy the list:
Eric Blossom wrote:
> On Tue, Apr 14, 2009 at 02:19:38PM -0500, Douglas Geiger wrote:
>
> Doug,
>
> I wouldn't expect the time stamps in the streams to start at the same
> point (the start_rx_streaming command doesn't accept a
On Thu, 2009-04-16 at 14:22 -0400, Marcus D. Leech wrote:
> Does the FPGA code for BASIC_RX support a Hilbert transform to convert
> one of the real inputs into a complex stream?
No, but if your signal of interest has a passband above DC, when you
"tune" the BasicRX, the complex mixer in the FPGA
So, just to help me understand, let's say that running as root wasn't a
problem. Like, if you didn't have to be root to open a raw socket.
Would that mean that the open_usrp2_socket() function would just look like
this
usrp2::open_usrp2_socket() {
int fd = socket(PF_PACKET, SOCK_RAW, ht
Does the FPGA code for BASIC_RX support a Hilbert transform to convert
one of the real inputs into a complex stream?
--
Marcus Leech
Principal Investigator, Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
___
Discuss-gnuradio mailing lis
Jason Uher wrote:
'good practices' option: Look at the benchmark_*x.py examples,
Thank you Jason. I will attempt the "good practice"-way first then :-)
--
Einar Thorsrud
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.or
Just a note from my experience with the USRP2 on our LAN, we didn't see any
problems initially, but something changed around RC1 that seriously disabled
LAN clients/switches in the immediate physical segment. We didn't look into
any further yet, but it was an instantaneous effect upon attaching a
On Thu, 2009-04-16 at 15:13 +, Juha Vierinen wrote:
> How accurate is sync_to_pps? Can you do MIMO with just sync_to_pps
> (assuming your cables are equal length)?
Yes. Two USRP2s synced to the same 10 MHz reference and PPS will have
sampling times accurate to the PPS arrival time, and will
> I wouldn't expect the time stamps in the streams to start at the same
> point (the start_rx_streaming command doesn't accept a "start at
> time T argument). I would expect that there is a constant delta_t
> between subsequent frames, and that that delta_t would be the same for
> both of the USRP
Ane Andersen wrote:
By the way I tried to do a make distclean. This didn't change the
result of the making and I didn't find anyother surgestions to solve
the problem in the old mails:-(
Update to the newest revision of the trunk. This was a bug in that
particular version you checked out.
This release compiles, checks, installs, and uninstalls properly on
OSX 10.5.6 / XCode 3.1.2 using Apple's GCC 4.2 and MacPorts (latest
everything, since there's not much choice), using both "normal" and
VPATH builds. Other pieces of good news:
* Looks like the GNU Radio build system and p
By the way I tried to do a make distclean. This didn't change the result of
the making and I didn't find anyother surgestions to solve the problem in
the old mails:-(
2009/4/15 Eric Blossom
> On Wed, Apr 15, 2009 at 04:59:15PM +0200, Ane Andersen wrote:
> > Hi Eric
> > ...Okey now I have anothe
>>Is there an easy way to get a vector source to pass on the same signal
>>over and over again, but with a fixed delay between each transmission?
'good practices' option: Look at the benchmark_*x.py examples, if you
drill down into the packet manager you will find an example of a
source block that
Dear all,
(Sorry for this "partial" OT).
We are looking for a student who is familiar with GNU radio and USRP/USRP2 for
a summer internship at the Telecommunications Research Center Vienna (Austria).
He will join another student for extending the existing IEEE802.11 code.
Candidate should be pr
Dimitris Symeonidis wrote:
Maybe use gr.valve?
Thank you. But still the vector source would need to be "rewinded" every
time, and the delay would have to some how control it all.
Do you have any more ideas or details?
- Einar
___
Discuss-gnuradi
Hi All,
i am searching for some more detailed explanation to the
ewma and average calculations in gnuradio.
There is something written at,
/usr/local/share/doc/gnuradio-3.2svn/html/classgr__peak__detector2__fb.html
So i think the average will only be calculated when the threshold does
find somethi
Maybe use gr.valve?
Dimitris Symeonidis
"If you think you're too small to make a difference, try sleeping with a
mosquito!" - Amnesty International
On Thu, Apr 16, 2009 at 10:40, Einar Thorsrud wrote:
> Hi all,
>
> Is there an easy way to get a vector source to pass on the same signal
> over a
...Sorry. I forgot a thing or two ;-) This is the makelog. Hopefully you
can help me now.
make all-recursive
make[1]: Entering directory `/home/tui104/boost_temp/gnuradio'
Making all in config
make[2]: Entering directory `/home/tui104/boost_temp/gnuradio/config'
make[2]: Nothing to be done for
Hi all,
Is there an easy way to get a vector source to pass on the same signal
over and over again, but with a fixed delay between each transmission?
The goal is to simulate the transmission of fixed size packets with a
fixed delay between each.
- Einar
___
Dimitris Symeonidis gmail.com> writes:
>
>
> Have you removed ALL gr.throttle blocks from your flowgraph?
I tried some combinations without any success, so i think it's a bug
and i have to wait for until it is solved. The throttle element
doesn't change anything for me.
Does any developer need
... and our theme is back! I ported it to 0.11
- George
On Wed, Apr 15, 2009 at 9:07 PM, George Nychis wrote:
> Hi everyone,
>
> The CGRAN upgrades are finally complete. After our server took a hit last
> week, I figured it was time to upgrade some things while I fixed some
> others. CGRAN
38 matches
Mail list logo
