Chris Stankevitz wrote:
3. Built and installed 3.1.3 (tar.gz)
Just upgraded to the trunk and unfortunately have the same problem.
(usrp_standard_rx* changed to a boost sptr, but otherwise code is the same.)
Chris
___
Discuss-gnuradio mailing list
Fix missing header include (Don Ward)
Modified: gnuradio/trunk/gnuradio-core/src/lib/missing/
posix_memalign.cc
===
#include posix_memalign.h
+#include malloc.h
This change breaks compile on OSX ... malloc.h is in /usr/include/
On Tue, Feb 10, 2009 at 6:09 AM, Michael Dickens m...@alum.mit.edu wrote:
This change breaks compile on OSX ... malloc.h is in /usr/include/malloc/ on
OSX, and is not needed on OSX or LINUX to be best of my knowledge for this
code to compile ... only for the Windows environment. Here's my
Yes, that works on OSX 10.5, and should be backwards compatible to
10.4 since /usr/include/stdlib.h exists on both OSs. - MLD
On Feb 10, 2009, at 9:24 AM, Johnathan Corgan wrote:
Can you try changing the include to stdlib.h to see if that works on
OSX?
On Mon, Feb 09, 2009 at 01:43:41PM +0100, Martin Braun wrote:
[code]
Here's what I don't understand: the state for the MA (as for all
filters) is saved implicitly in the history. However, in this special
case, the state is simply one scalar value (saved in 'sum'). The way
this is
Michael Dickens wrote:
Fix missing header include (Don Ward)
Modified: gnuradio/trunk/gnuradio-core/src/lib/missing/
posix_memalign.cc
===
#include posix_memalign.h
+#include malloc.h
This change breaks compile on OSX ...
On Feb 10, 2009, at 10:11 AM, Don Ward wrote:
Oops, this is my mistake. I should have seen that valloc() is
supposed to be in stdlib.h (but isn't there in Cygwin). Thanks
for fixing this.
I'm worried, though, that valloc isn't available at all on MinGW.
Is there another way to
- Original Message -
From: Michael Dickens m...@alum.mit.edu
To: Don Ward don2387w...@sprynet.com
Cc: GNU Radio Discussion discuss-gnuradio@gnu.org
Sent: Tuesday, February 10, 2009 10:32 AM
Subject: Re: [Discuss-gnuradio] Re: [Commit-gnuradio]
r10410
Eric Blossom wrote:
Hi Charles,
You have to tell it to use them.
Take a look in usrp2/usrp2.h:
config_mimo(MC_WE_LOCK_TO_SMA)
sync_to_pps()
There are python bindings for these.
(Oops, looks like we're missing the python binding for config_mimo...)
Are you using this from
Michael,
thank you for help! It turned out that I had set the DYLD_LIBRARY_PATH
for my Matlab, so that I could interface it with Java. Also, the
PKG_CONFIG_PATH hadn't been set at all. After removing the
DYLD_LIBRARY_PATH and setting the PKG_CONFIG_PATH I managed to compile
3.1 release from svn.
Hi Jakob - Good to hear you got GNU Radio running on your OSX
install. All of the bootstrap warnings and the failed tests on OSX
have been corrected in the latest trunk; I highly recommend updating
to it (svn up) if you have the time. - MLD
On Feb 10, 2009, at 11:55 AM, Jakub Moskal
Whoops,
forget about skipping the history(), of course it couldn't work.
However, by adding a state buffer to the class, the first for() loop
can be skipped. For long MAs, this would save some multiplications and
only increase memory usage by one item_size.
The reason we don't do that is that
Eric and Doug,
I like Doug am basing things off the rx_streaming_samples.cc. It seemed
easier to work with to get access to timestamps.
Charles
-Original Message-
From: discuss-gnuradio-bounces+csuprin=mitre@gnu.org
[mailto:discuss-gnuradio-bounces+csuprin=mitre@gnu.org]
Michael,
I checkout the latest trunk, bootstrap finished without any warnings.
The configure finished in the same way as it did for the 3.1 release.
However, when trying to compile I get the following error:
In file included from ./gr_msg_queue.h:26,
from gr_msg_queue.cc:26:
On Tue, Feb 10, 2009 at 10:48:18AM -0600, Douglas Geiger wrote:
Eric Blossom wrote:
You have to tell it to use them.
Take a look in usrp2/usrp2.h:
config_mimo(MC_WE_LOCK_TO_SMA)
sync_to_pps()
There are python bindings for these.
(Oops, looks like we're missing the
On Mon, Feb 09, 2009 at 11:34:17PM -0800, Chris Stankevitz wrote:
Johnathan Corgan wrote:
On Mon, Feb 9, 2009 at 7:07 PM, Chris Stankevitz cstankev...@toyon.com
wrote:
I wrote a c++ program that grabs data from the USRP in an infinite loop
and does nothing with it. It overruns. Can
Eric Blossom wrote:
Since I've now tried this a few times
doing things like: removing the antenna from one (and not the other),
moving them far apart, etc. - I'm fairly certain this is a software
problem, and not the correct results.
OK. Just to be sure, are you explicitly specifying
Douglas Geiger wrote:
This is with no 1PPS, no 10Mhz reference signal, and the antenna on
30:80 was removed (installed on 30:81). I'm going to pull up wireshark
to compare the frames I'm getting from each USRP2.
Doug
Ok, looking at the frames in wireshark, looking for the timestamps that
On Feb 10, 2009, at 1:35 PM, Jakub Moskal wrote:
I checkout the latest trunk, bootstrap finished without any warnings.
The configure finished in the same way as it did for the 3.1 release.
However, when trying to compile I get the following error:
In file included from ./gr_msg_queue.h:26,
On Tue, Feb 10, 2009 at 1:26 PM, Douglas Geiger
doug.gei...@bioradiation.net wrote:
Ok, looking at the frames in wireshark, looking for the timestamps that
were sent to the copy handler, it looks like only the frames from 30:80
are being used, and they're being used twice (i.e.
Martin DvH wrote:
On Tue, 2009-02-03 at 10:38 -0800, chitlas wrote:
Hi,
Please let me know from where I can purchase USRP1 / USRP2 as I see that
USRP2 is due for release (beta is no longer available) and USRP1 is out of
stock till Feb end or so from ETTUS's site.
Thanks in advance.
Chris Stankevitz wrote:
Question: Why would 2 channels at 4MHz overrun while 1 channel at 8MHz
not overrun?
Fantastic news (for me): this problem does not occur in gnuradio 3.0.2
I thought to try an older version of gnuradio after I made the
realization (with the help of a coworker) that my
On Feb 10, 2009, at 11:17 AM, Don Ward wrote:
As far as I can tell, MinGW has no standard aligned-memory
allocation functions. Can we use malloc16.c (in gnuradio-core/.../
general) or something like gcell/lib/runtime/gc_aligned_alloc.cc
instead?
malloc16.c requires the use of both the
Chris Stankevitz wrote:
Chris Stankevitz wrote:
Fantastic news (for me): this problem does not occur in gnuradio 3.0.2
I thought to try an older version of gnuradio after I made the
realization (with the help of a coworker) that my overrun problems are
worse today than they were a year
George Nychis wrote:
Hi all,
CGRAN will likely be down for several hours today while we work on
assigning it its own IP address and updating its SSL certificate.
CGRAN is back up and running now. We are using IP-based virtual hosting
on the base machine to better separate.
Due to
On Tue, Feb 10, 2009 at 11:12 PM, George Nychis gnyc...@cmu.edu wrote:
Due to this, I could make our base SVN URL:
https://www.cgran.org/
...instead of:
https://www.cgran.org/cgran/
But, this would mean that everyone would need to re-checkout anything
outstanding. I think our biggest
Frank Brickle wrote:
On Tue, Feb 10, 2009 at 11:12 PM, George Nychis gnyc...@cmu.edu
mailto:gnyc...@cmu.edu wrote:
Due to this, I could make our base SVN URL:
https://www.cgran.org/
...instead of:
https://www.cgran.org/cgran/
But, this would mean that everyone would
Hi,
I tried your code and also got overruns. I have had better luck by
increasing the fusb_blocksize and fusb_nblocks to really large values
like fusb_blocksize=4096 and fusb_nblocks=4096 (or sometimes even
16384). In my opinion the default values are too small.
I made the following modification
Hi Michael,
unfortunately I do need omniORB and omniORBpy, so I don't want to
uninstall them... The CPATH is not set. Do you think that temporarily
removing it, compiling gnuradio and installing it back on would do the
trick?
Thanks a lot for your help!!
Jakub
On Tue, Feb 10, 2009 at 4:38 PM,
Hi,
Does anyone knows the way to clear the receive buffer in
benchmark_rx?Regards,Joreen
_
More than messages–check out the rest of the Windows Live™.
Hi,
Our research group is looking for a summer trainee to work with USRP
and Gnuradio related tasks. Our main application area is statistical
modeling and analysis of high power large aperture radar measurements.
We are currently working with inverse synthetic aperture radar,
incoherent scatter
31 matches
Mail list logo
