[Discuss-gnuradio] Software Defined Radio Direction Finding (SDRDF)

[Balint Seeber]

Hi  folks,

For those of you interested in Radio Direction Finding, I would like to
share this video:

http://www.youtube.com/watch?v=NSC4Y8yA-jY

of a presentation I gave recently about DF in general, and my homebrew
(auto-)mobile SDRDF system using the USRP and GNU Radio.

Any questions/comments are most welcome!

Balint @spenchdotnet  

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] How to change modulation of examples/digital/ofdm/benchmark_rx.py dynamically

[Yubo Yan]

Hi all,

I am testing benchmark_rx.py in examples/digital/ofdm/ directory. I want
change the modulation method dynamically when the flow graph is running. On
way is that lock, disconnect, reconfigure, connect and then unlock flow
graph. However, this way is often lead to program stuck. So is there any
way else to change the modulation dynamically?

Regards,

Yubo
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GR 3.5.1 & OSX

[Carles Fernandez]

Thanks for the hint. It seems that there is a problem with the
libfreetype library:

$  python
Python 2.7.2 (default, Jan 21 2012, 15:35:05)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import gtk
Traceback (most recent call last):
  File "", line 1, in 
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gtk-2.0/gtk/__init__.py",
line 40, in 
from gtk import _gtk
ImportError: 
dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gtk-2.0/gtk/_gtk.so,
2): Library not loaded: /opt/local/lib/libfreetype.6.dylib
  Referenced from:
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gtk-2.0/gtk/_gtk.so
  Reason: Incompatible library version: _gtk.so requires version
15.0.0 or later, but libfreetype.6.dylib provides version 14.0.0

I will try to fix this.  I will post the solution in case of success,
maybe can be useful to others.

Best regards,
Carles



On Sun, Mar 4, 2012 at 4:58 AM, Michael Dickens  wrote:
> Hmm ... not sure what's going on.  When you're in Python, can you do "import 
> gtk" successfully?  That's what CMake is testing for, roughly.  If it can't, 
> hopefully the error will shed some light as to what's going on. - MLD
>
> On Mar 3, 2012, at 9:16 PM, Carles Fernandez wrote:
>
>> Well, actually I had the gnuradio port already and I did a "sudo port
>> uninstall gnuradio" before all the building process. I saw that I have
>> py27-gtk installed but python version is 2.6.7...so I did:
>>
>> $ sudo port select python python27
>> $ python -V
>> Python 2.7.2
>>
>> but when I do
>>
>> $ cmake ../
>>
>> I stiil get
>>
>> -- Configuring gnuradio-companion support...
>> --   Dependency ENABLE_GR_CORE = ON
>> --   Dependency ENABLE_PYTHON = ON
>> --   Dependency PYTHON_MIN_VER_FOUND = TRUE
>> --   Dependency CHEETAH_FOUND = TRUE
>> --   Dependency LXML_FOUND = TRUE
>> --   Dependency PYGTK_FOUND = FALSE
>> --   Dependency NUMPY_FOUND = TRUE
>> --   Disabling gnuradio-companion support.
>>
>>
>> Is there any step I'm missing?
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GR 3.5.1 & OSX

[Michael Dickens]

It looks like you have a mixed install, somehow, of MacPorts stuff; some older, 
some newer.  If you haven't done it recently, I'd recommend:

sudo port selfupdate
sudo port upgrade outdated

and, if that breaks, do:

sudo port clean outdated
sudo port -p upgrade outdated

and then report the issues on a MP ticket if a search on active tickets turns 
up nothing.  My guess is that doing the above will fit the issue. - MLD

On Mar 4, 2012, at 8:24 AM, Carles Fernandez wrote:

> Thanks for the hint. It seems that there is a problem with the
> libfreetype library:
> 
> $  python
> Python 2.7.2 (default, Jan 21 2012, 15:35:05)
> [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
 import gtk
> Traceback (most recent call last):
>  File "", line 1, in 
>  File 
> "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gtk-2.0/gtk/__init__.py",
> line 40, in 
>from gtk import _gtk
> ImportError: 
> dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gtk-2.0/gtk/_gtk.so,
> 2): Library not loaded: /opt/local/lib/libfreetype.6.dylib
>  Referenced from:
> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gtk-2.0/gtk/_gtk.so
>  Reason: Incompatible library version: _gtk.so requires version
> 15.0.0 or later, but libfreetype.6.dylib provides version 14.0.0
> 
> I will try to fix this.  I will post the solution in case of success,
> maybe can be useful to others.


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] building carrier sense in the FPGA and UHD

[Andre Puschmann]

George,

On 03/04/2012 12:51 AM, George Nychis wrote:
> Hi all,
> 
> I'm going to be hacking carrier sense in to the FPGA on the USRP2 very
> soon.  Basically, taking what I did with the "in-band" project from the
> USRP1 with carrier sense, and moving it forward to USRP2. 
> 
> The idea is, just like you can set a timestamp to "gate" a packet on its
> way out: only transmit it at time X, you can do something similar with
> carrier sense.  If the burst has the carrier sense flag set, then you
> wait for the carrier to become idle, then transmit the packet.
> 
> For the in-band implementation, I had a command to set the value at
> which the carrier is determined to be busy/idle.  This was stored in
> memory in the FPGA.  Then, when bursts came with a carrier sense bit
> set, that value is used.
> 
> OK:  so I'd like to re-do this implementation to keep this kind of stuff
> alive, and I will use it myself.  But in doing so, I'd like to implement
> it in a way that jives well with the higher ups.  If I'm going to do it,
> I'd like to do it right so that it lives on through future versions of
> GNU Radio.  So that means doing it using UHD.
> 
> For the life of me, I can't find the UHD header spec.  But I imagine
> somewhere in there we can fit a bit to gate based on carrier sense, and
> a new command to set the carrier sense threshold.
> 
> If you have any advice/guidance on how you'd like to see this
> implemented, let me know.  I sincerely would like this to live long and
> prosper in GNU Radio and the USRPs.

I totally like and support your idea and would love to help realizing
it. Using the timestamp logic inside UHD as a reference is a great idea
that also came to my mind a while ago.
There are a few things from the architecture point of view though that
need to be discussed. Let's take a CSMA MAC as an example, I guess that
goes into the right direction :-) Just having the "if channel free,
transmit packet"-logic inside the FPGA wouldn't make much sense in a
multi-user environment. What would happen is that if the channel is busy
and multiple nodes have packets in their tx queues, they would all end
up sending their packets more or less at the same time after the channel
gets idle again (assuming all nodes are in sensing range). In a
practical system, one would now start to move parts of the CSMA state
machine, i.e the random backoff, into the FPGA. Trying to control this
via UHD is probably a bad idea as UHD's main business is transportation.

I do think we need something like what you have suggested but I am still
a bit puzzled about the right way of implementing it.

Best regards,
Andre


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] building carrier sense in the FPGA and UHD

[Marcus D. Leech]

George,

I do think we need something like what you have suggested but I am still
a bit puzzled about the right way of implementing it.

Best regards,
Andre

I think a more fundamental issue is that "carrier sense" isn't actually 
defined in any kind of general way.  Certainly for *some* types of
  PHYs, you can do simple energy-presence detection.  But usually, it's 
more complicated than that, and it varies widely from PHY to
  PHY.  In some, you'll need to run a correlator before you even know 
whether the channel is busy or not.  In others, simple energy

  detection works.

I don't think there's a general-purpose way of doing this, but that's 
just my POV.


--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] building carrier sense in the FPGA and UHD

[George Nychis]

>
>
> I totally like and support your idea and would love to help realizing
> it. Using the timestamp logic inside UHD as a reference is a great idea
> that also came to my mind a while ago.
> There are a few things from the architecture point of view though that
> need to be discussed. Let's take a CSMA MAC as an example, I guess that
> goes into the right direction :-) Just having the "if channel free,
> transmit packet"-logic inside the FPGA wouldn't make much sense in a
> multi-user environment. What would happen is that if the channel is busy
> and multiple nodes have packets in their tx queues, they would all end
> up sending their packets more or less at the same time after the channel
> gets idle again (assuming all nodes are in sensing range). In a
> practical system, one would now start to move parts of the CSMA state
> machine, i.e the random backoff, into the FPGA. Trying to control this
> via UHD is probably a bad idea as UHD's main business is transportation.
>
> I do think we need something like what you have suggested but I am still
> a bit puzzled about the right way of implementing it.
>
>
Hi Andre,

Yeppp, the idea is to build part of the MAC in to the FPGA... the part that
requires low latency operation.  So, after the simple "transmit when idle"
logic, you put some basic form of back off in to the logic also.

I have a paper which argues low latency MAC functionality should be built
in to the FPGA, but controlled from the host, otherwise it's as good as
worthless implementing it on the host.  If you try to build this part of
the MAC at the host, the latency of receiving the channel state (latency
from FPGA -> host), making a decision and performing an action (host ->
FPGA), completely makes the information stale.  You end up with a decision
that is something like 1-2ms old, which clearly the state of the channel
changes at a more finer-grain than that.

Sooo... you either implement this kind of functionality in a "split" kind
of way where the function sits in the FPGA since it requires low latency,
or it's as good as worthless ;)  I'd rather have some form of carrier sense
that's commonly used in some side-FPGA implementation, rather than throwing
in the towel and saying GNU Radio and the USRP's architecture can never
support something like this that's usable due to the latency.  I get tons
of e-mails about my split-functionality MAC work, asking if it's usable but
it got deprecated along with the m-block, so there is a set of users out
there that I think would be happy with some basic usable carrier sense and
back-off.  Otherwise we're constantly in the: let's avoid the whole idea of
support a true MAC thing, and GNU Radio and USRP continue life as a
source/sink.

(http://dl.acm.org/citation.cfm?id=1558984)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] building carrier sense in the FPGA and UHD

[Marcus D. Leech]

Definitely, there are MACs whose form of carrier sense is detecting 
preamble rather than detecting energy.  In my same piece of work, we 
put a matched filter in the FPGA and the host specifies the 
coefficients of the match filter, then you gate on that.  But, I don't 
think it's unreasonable to think basic energy detection is not general 
purpose enough?  I think supporting some basic form of energy 
detection would start to enable better MAC implementations...


and afterwards I have every intention of rolling a match filter in to 
the FPGA also.  So, maybe your suggestion is I build a separate FPGA 
implementation if people want MAC functionality.  I can do that if 
people believe that the functionality is not general enough.
Given that there are a metric-arseload (that's a scientific measure, btw 
:-) ) of applications for Gnu Radio and USRP hardware that have
  nothing at all to do with data communications of any kind, such a 
thing fails *my personal* definition of a "generality test".  But there are
  enough folks using this stuff for data communications that perhaps it 
would be worthwhile.




--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] building carrier sense in the FPGA and UHD

[George Nychis]

On Sun, Mar 4, 2012 at 10:01 AM, Marcus D. Leech  wrote:

> George,
>>
>>
>> I do think we need something like what you have suggested but I am still
>> a bit puzzled about the right way of implementing it.
>>
>> Best regards,
>> Andre
>>
>>  I think a more fundamental issue is that "carrier sense" isn't actually
> defined in any kind of general way.  Certainly for *some* types of
>  PHYs, you can do simple energy-presence detection.  But usually, it's
> more complicated than that, and it varies widely from PHY to
>  PHY.  In some, you'll need to run a correlator before you even know
> whether the channel is busy or not.  In others, simple energy
>  detection works.
>
> I don't think there's a general-purpose way of doing this, but that's just
> my POV.
>
>
Definitely, there are MACs whose form of carrier sense is detecting
preamble rather than detecting energy.  In my same piece of work, we put a
matched filter in the FPGA and the host specifies the coefficients of the
match filter, then you gate on that.  But, I don't think it's unreasonable
to think basic energy detection is not general purpose enough?  I think
supporting some basic form of energy detection would start to enable better
MAC implementations...

and afterwards I have every intention of rolling a match filter in to the
FPGA also.  So, maybe your suggestion is I build a separate FPGA
implementation if people want MAC functionality.  I can do that if people
believe that the functionality is not general enough.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] building carrier sense in the FPGA and UHD

[Andre Puschmann]

On 03/04/2012 04:01 PM, Marcus D. Leech wrote:
>> George,
>>
>> I do think we need something like what you have suggested but I am still
>> a bit puzzled about the right way of implementing it.
>>
>> Best regards,
>> Andre
>>
> I think a more fundamental issue is that "carrier sense" isn't actually
> defined in any kind of general way.  Certainly for *some* types of
>   PHYs, you can do simple energy-presence detection.  But usually, it's
> more complicated than that, and it varies widely from PHY to
>   PHY.  In some, you'll need to run a correlator before you even know
> whether the channel is busy or not.  In others, simple energy
>   detection works.
> 
> I don't think there's a general-purpose way of doing this, but that's
> just my POV.

You're absolutely right, Marcus. I also think it'd be quite difficult to
find a truly general-purpose solution to that.

Knowing George's field of interested, I was assuming something like a
simple energy detector. I think even this simple example shows the
difficulties quite clearly.

-Andre


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] building carrier sense in the FPGA and UHD

[Andre Puschmann]

On 03/04/2012 04:10 PM, George Nychis wrote:
> 
> I totally like and support your idea and would love to help realizing
> it. Using the timestamp logic inside UHD as a reference is a great idea
> that also came to my mind a while ago.
> There are a few things from the architecture point of view though that
> need to be discussed. Let's take a CSMA MAC as an example, I guess that
> goes into the right direction :-) Just having the "if channel free,
> transmit packet"-logic inside the FPGA wouldn't make much sense in a
> multi-user environment. What would happen is that if the channel is busy
> and multiple nodes have packets in their tx queues, they would all end
> up sending their packets more or less at the same time after the channel
> gets idle again (assuming all nodes are in sensing range). In a
> practical system, one would now start to move parts of the CSMA state
> machine, i.e the random backoff, into the FPGA. Trying to control this
> via UHD is probably a bad idea as UHD's main business is transportation.
> 
> I do think we need something like what you have suggested but I am still
> a bit puzzled about the right way of implementing it.
> 
> 
> Hi Andre,
> 
> Yeppp, the idea is to build part of the MAC in to the FPGA... the part
> that requires low latency operation.  So, after the simple "transmit
> when idle" logic, you put some basic form of back off in to the logic
> also.  
> 
> I have a paper which argues low latency MAC functionality should be
> built in to the FPGA, but controlled from the host, otherwise it's as
> good as worthless implementing it on the host.  If you try to build this
> part of the MAC at the host, the latency of receiving the channel state
> (latency from FPGA -> host), making a decision and performing an action
> (host -> FPGA), completely makes the information stale.  You end up with
> a decision that is something like 1-2ms old, which clearly the state of
> the channel changes at a more finer-grain than that.

Well, I believe it's just a matter of scaling the whole system by the
right factor. Information that is 1ms old can still be valuable if it
still represents the truth.

I just don't want to loose all the flexibility of software by moving the
critical but interesting things to hardware.

But of course, it all depends upon your goals.

-Andre


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] building carrier sense in the FPGA and UHD

[Darren Long]

In the amateur radio world, AX.25 "packet radio" terminal node
controllers supported  KISS mode, which left the CSMA and HDLC framing
in the TNC but offloaded the state-machine for connection management to
the host CPU stack. 

KISS merely provided a way to forward the frame metadata and payload
over the serial link between the TNC and the host.  With buffering at
each end of the serial link to the TNC, knowing exactly when a specific
frame of data has been transmitted on air is impossible and this causes
some grief in the Linux kernel's internal implementation of the state
machines for connected mode AX.25, specifically when scheduling
retransmissions.

To be fair, we are talking about fairly large buffers and fairly low
bit-rates on tx here - 1200 baud typically, but nugatory retransmission
due to channel state backoff without backpressure is a bugger.

I assume that we would want a control plane that can provide that kind
of feedback, and would want some way of tagging transmission data units
as requiring some kind of notification of transmission on-air. 

I'm very new in the gr world so can't talk with authority on anything
other than provide vague waffle such as this for your consideration.

Cheers,

Darren, G0HWW

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] cmake destination on 64-bit machines

[John Coppens]

Hello all,

Cmake seems to insist on installing all libraries in /usr/local/lib
instead on /usr/local/lib64. I can't find an obvious way to define
a destination path in cmake, or an architecture.

My machine is an AMD64, running Slackware, where the difference between
32 and 64 bit libraries is defined by the directories. So, the
installation in lib causes quite a few problems...

What I found until now:
Tracing the execution of cmake:

CMakeSystem.cmake(6):  SET(CMAKE_SYSTEM_PROCESSOR x86_64 )
GrPlatform.cmake(43):  if(NOT DEFINED LIB_SUFFIX AND REDHAT AND 
CMAKE_SYSTEM_PROCESSOR MATCHES 64$ ) 
GrPlatform.cmake(46):  set(LIB_SUFFIX ${LIB_SUFFIX} CACHE STRING lib directory 
suffix )

REDHAT isn't defined (I believe) and neither is LIB_SUFFIX. So I tried to run 
cmake:

cmake --DREDHAT --DLIB_SUFFIX=64 ..

Still installs in lib instead of lib64.

Suggestions Please!

John

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] cmake destination on 64-bit machines

[Josh Blum]

> cmake --DREDHAT --DLIB_SUFFIX=64 ..
> 
> Still installs in lib instead of lib64.
> 

I think its the double dashes. Try -DLIB_SUFFIX=64

-josh

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Volk update to master/next

[Andrew Davis]

Ok, false alarm with my bug, apparently the compiler checks the old
installed volk directory first, once I cleaned out my system include
dir it compiled fine.

There is a noticeable difference on my old P4 with sse3 in everything
GNU Radio related! This is great stuff!

On Sat, Mar 3, 2012 at 5:52 PM, LRK  wrote:
> On Sat, Mar 03, 2012 at 03:00:14PM -0500, Andrew Davis wrote:
>> >[ 25%] Building CXX object 
>> >gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/general/gr_add_ff.cc.o
>> >/home/glneo/gnuradio/gnuradio-core/src/lib/general/gr_add_ff.cc: In member 
>> >function 'virtual int gr_add_ff::work(int, gr_vector_const_void_star&, 
>> >gr_vector_void_star&)':
>> >/home/glneo/gnuradio/gnuradio-core/src/lib/general/gr_add_ff.cc:59: error: 
>> >'volk_32f_x2_add_32f_u' was not declared in this scope
>>
>> breaks on this over here in FreeBSD land. In volk.h:
>
>  I built this morning without this error. Recent FreeBSD:
> FreeBSD 8.2-STABLE #6: Wed Jan 25
>
> and ports updated as of this morning.
>
> -- ##
> -- # Gnuradio disabled components
> -- ##
> --   * doxygen
> --   * gr-comedi
> --   * gr-shd
> --
> -- Using install prefix: /log/gr/gr352/local
> -- Building for version: v3.5.1-196-g4f0add17 / 3.5.2git
>
>
>  Doesn't eat all the CPU time even in dial_tone.py like it has until
> now. Progress!
>
>
> --
>    The computer is supposed to work for YOU, not the other way around.
> LRK
> gr-user . ovillatx.sytes.net

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] building carrier sense in the FPGA and UHD

[George Nychis]

Let me put it this way... I'm going to build it because I need it ;)  But
what I'm asking/hoping for is for it to be useful beyond just me and
actually have a lifespan beyond my immediate use of it.  So, I'd like to
get some feedback on how others might like to see it tied in to UHD, or the
type of flexibility the implementation should have.  For example, the
programmability of the threshold, the type of back off, the control of the
back off, etc.

You don't get these types of people on the list very often because they
simply look at GNU Radio and USRPs architecture and go: well, it doesn't
support that... moving right along to another platform (e.g., WARP, Sora,
etc.).  But speaking from my area (wireless networking, not so much
wireless communications), it is this kind of functionality that a lot of
people want/need to build a network on top of the OFDM code, for example.

You can say that energy sensing isn't general enough or any implementation
of it wouldn't be general enough, but IMO staying away from it more
significantly limits possible applications of the platform rather than
expanding it.  I think this type of functionality can further support a new
set of applications and networks.  I don't feel as though it threatens the
flexibility of GNU Radio because it's not fundamentally changing the
architecture. It's exploiting the tight-control that UHD was put in place
to try and enable. It's functionality that sleeps in the FPGA unless you
need it to build your application.

Like I said, I can build it as a separate FPGA firmware for those who want
to use the functionality (though I fear it gets deprecated quite quickly in
that way)... but it would be good to hear what kind of functionality and
flexibility people would like to see in a carrier sense implementation, how
it could be controlled, etc.  Otherwise, I will go off and "do my thang"
and you simply get what comes out of it ;)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Volk update to master/next

[Tom Rondeau]

On Sun, Mar 4, 2012 at 12:30 PM, Andrew Davis wrote:

> Ok, false alarm with my bug, apparently the compiler checks the old
> installed volk directory first, once I cleaned out my system include
> dir it compiled fine.
>
> There is a noticeable difference on my old P4 with sse3 in everything
> GNU Radio related! This is great stuff!


Andrew,
Glad to hear it's working well for you! I was going to suggest something
like that, since I had a similar situation on the E100.

Tom




> On Sat, Mar 3, 2012 at 5:52 PM, LRK  wrote:
> > On Sat, Mar 03, 2012 at 03:00:14PM -0500, Andrew Davis wrote:
> >> >[ 25%] Building CXX object
> gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/general/gr_add_ff.cc.o
> >> >/home/glneo/gnuradio/gnuradio-core/src/lib/general/gr_add_ff.cc: In
> member function 'virtual int gr_add_ff::work(int,
> gr_vector_const_void_star&, gr_vector_void_star&)':
> >> >/home/glneo/gnuradio/gnuradio-core/src/lib/general/gr_add_ff.cc:59:
> error: 'volk_32f_x2_add_32f_u' was not declared in this scope
> >>
> >> breaks on this over here in FreeBSD land. In volk.h:
> >
> >  I built this morning without this error. Recent FreeBSD:
> > FreeBSD 8.2-STABLE #6: Wed Jan 25
> >
> > and ports updated as of this morning.
> >
> > -- ##
> > -- # Gnuradio disabled components
> > -- ##
> > --   * doxygen
> > --   * gr-comedi
> > --   * gr-shd
> > --
> > -- Using install prefix: /log/gr/gr352/local
> > -- Building for version: v3.5.1-196-g4f0add17 / 3.5.2git
> >
> >
> >  Doesn't eat all the CPU time even in dial_tone.py like it has until
> > now. Progress!
> >
> >
> > --
> >The computer is supposed to work for YOU, not the other way around.
> > LRK
> > gr-user . ovillatx.sytes.net
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] cmake destination on 64-bit machines

[John Coppens]

On Sun, 04 Mar 2012 09:20:07 -0800
Josh Blum  wrote:

> > Still installs in lib instead of lib64.
> > 
> 
> I think its the double dashes. Try -DLIB_SUFFIX=64

Yes! Thanks... But why the double dash on --DREDHAT ?

John

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNURadio Pre Configured Virtual Image with GUI Front End

[Alexander List]

Ali,

given that you haven't received any responses so far, I guess this means 
there are not so many people out there who are willing to share their 
images ;)


It might be useful to create such an image, but in the free software 
world, you're more likely to find people using KVM or Xen instead of 
VMware or Parallels.


What exactly is it that you would like to do with GNUradio?

Why does it have to be in a VM instead of directly installing on your 
Mac (I assume you have a MAC, given that you mention Parallels)?


Are you aware that some stuff you might to do with GNU radio is latency 
sensitive, so your mileage using a VM might vary...


Alex

On 01/-9/-28163 03:59 AM, ali sajjad wrote:

Hi
 everyone
  i am newbie to GNURadio and wish to have Pre Configured 
GNURadio vmware or Parallels image

please share the information


thanks in advance

Best Regards

Bye





___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio