Re: [Discuss-gnuradio] New build structure! (Warning #2)

[Paul M. Bendixen]

Hi happy to hear it, autotools were complaining about old syntax on my
machine

Using gentoo (not too heavily updated I'm afraid) and not succeding

Configuring using cmake went well, but compiling didn't, already at first
stop volk (that I'm not entirely sure i need) a _lot_ of errors occured.
To be more specific, more than my shell history could take.



2011/10/20 Tom Rondeau 

> [snip]
> $ cd gnuradio
> $ git checkout next
> $ git pull
> $ mkdir build
> $ cd build
> $ cmake ../
>
Up to here it went well

> $ make
>
This fails already at volk

> $ make test
> $ sudo make install
>
> Is there any way to disable parts such as volk? (akin to --disable-volk
that doesn't seem to work)

The errors seems to be syntax errors in volk. Errors include:

"In file included from
/home/expert/skole/speciale/GnuRadio/git/build/volk/lib/volk.c:6:
/home/expert/skole/speciale/GnuRadio/git/build/volk/lib/volk_machines.h:20:
fejl: expected ':', ',', ';', '}' or '__attribute__' before
'volk_16i_branch_4_state_8_a_archs'
" (the first one, fejl means error in danish)

Any other outputs I can provide to help, just ask.



> Again, if that fails but you really need to use the current next branch,
> the same autotools build process will work. Please let us know if you find
> any issues.
>
> Thanks, I'll just checkout master again ;)

Best
Paul M. Bendixen

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

Re: [Discuss-gnuradio] Warning! Warning!

[Rafael Diniz]

Morning people,
Is there any web interface where we can see the git changes?

Best regards,
Rafael Diniz

> We are REMOVING the USRP and USRP2 components from GNU Radio!
>
> It's been mentioned in the past, but the change on the next branch
> is imminent. As of GNU Radio 3.5, we will no longer support libusrp,
> libusrp2 or the GNU Radio interfaces, gr-usrp and gr-usrp2. Everything is
> moving to using UHD.
>
> If you have not started to port your code over to using the UHD driver,
> start thinking about it now. Follow the changes that were made in 'next'
> to
> convert the old examples that used to use the gr-usrp/usrp2 interfaces to
> gr-uhd.
>
> This also reduces the number of dependencies required. Updates on this
> will
> be posted on the wiki when it becomes the stable release.
>
> Tom



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

Re: [Discuss-gnuradio] build-gnuradio under Ubuntu 11.10

[Marcus D. Leech]

On 20/10/11 01:51 AM, Dan CaJacob wrote:
> It worked for me on Ubuntu 11.10 x64
>
>
>   
Thanks!

> On Oct 17, 2011, at 1:31 PM, "Marcus D. Leech"  wrote:
>
>   
>> Could somebody try build-gnuradio under Ubuntu 11.10 and give me feedback 
>> about work/not-work.  There's currently
>>  a pre-reqs paragraph for "11.*", which may or may not work under 11.10.
>>
>>
>>
>>
>> 
>
>   


-- 
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] Warning! Warning!

[Philip Balister]

On 10/20/2011 07:57 AM, Rafael Diniz wrote:
> Morning people,
> Is there any web interface where we can see the git changes?

http://gnuradio.org/cgit/gnuradio.git/

I find cloning the git repo and using qgit gives a much clearer picture
of how the branches work though.

Philip

> 
> Best regards,
> Rafael Diniz
> 
>> We are REMOVING the USRP and USRP2 components from GNU Radio!
>>
>> It's been mentioned in the past, but the change on the next branch
>> is imminent. As of GNU Radio 3.5, we will no longer support libusrp,
>> libusrp2 or the GNU Radio interfaces, gr-usrp and gr-usrp2. Everything is
>> moving to using UHD.
>>
>> If you have not started to port your code over to using the UHD driver,
>> start thinking about it now. Follow the changes that were made in 'next'
>> to
>> convert the old examples that used to use the gr-usrp/usrp2 interfaces to
>> gr-uhd.
>>
>> This also reduces the number of dependencies required. Updates on this
>> will
>> be posted on the wiki when it becomes the stable release.
>>
>> Tom
> 
> 
> 
> ___
> 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] New build structure! (Warning #2)

[Martin Braun]

> Details about using cmake can be found here:
> http://gnuradio.org/redmine/projects/gnuradio/wiki/CMakeWork

I'm loving it! And less build stuff thanks to the lack of usrp*...
great!

One thing that doesn't work perfect here: I always have to run
'ldconfig' after installation. Couldn't that be part of 'make install'
(or am I the only one who has this problem?).

MB

-- 
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association



pgpOOsZ9aXWhU.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Fw: Call for Papers: (ICC2012) SaCoNeT-III

[Sajjad Ali Mushtaq]

Please accept our apologies in advance , if you receive this CFP multiple times.

==
Please Spread the word!


Call for Papers

3rd IEEE International Workshop on SmArt COmmunications in NEtwork Technologies 
(SaCoNeT-III)

http://www.lissi.fr/saconet2012/doku.php

to be held in conjunction with IEEE ICC 2012 Conference
that will be held in Ottawa, Canada, June 11, 2012.

For paper submission, please follow the following link.

http://edas.info/N11473


Paper submission deadline November 30, 2011
==
As continuity of the first and the second edition of SaCoNeT 
workshop, the scope of SaCoNeT-III is to deal with the growing overlap 
between both autonomous systems and the future generation of network 
technologies embedded in Internet and cloud computing for a wide variety of 
applications (underwater, vehicular, medical, robotic, etc.). 
SaCoNet focused on how smart communications has affect some aspects 
(protocols, design, equipment, algorithms, paradigm, power, etc.) for a 
large family of applications (Healthcare, Medical, Underwater, 
Vehicular, Robotic, etc.) using network technologies (Sensor Networks, 
MaNet, VANET, etc.). Indeed, autonomous applications embedded in complex 
configurations and dynamic environments have rapidly expanded from 
classical applications where different modular devices, actuators and 
sensors interact closely. This has impacted considerably the control of a given 
system in a centralized manner. Current trends are to propose new autonomic 
architecture schemes that manage and control 
future emerging networks: sky of clouds, Internet of things, etc. 
Healthcare and wellness applications such as helping elderly people, 
assisting dependent persons, habitat monitoring in a smart environment 
constitute some of the potential scenarios of convergence between 
autonomous systems and smart network technologies. These applications, 
(which are based on high-level commands) accomplish some specific tasks, reveal 
new challenges regarding mechanic design, portability, 
acceptability, power support and efficiency, control theory, etc. In 
addition to portability and low-power systems, which are vital 
challenges that limit substantially the efficiency of any autonomous 
system based application; network paradigms should also take into 
account issues related to cost, scalability and security. This workshop 
will highlight the overlapping of these two domains of autonomous 
systems and the smart network technologies devoted for different applications 
for a 
large variety of domains: Healthcare, Medical, Underwater, Vehicular, 
Robotic, etc. Issues related to concepts, new technologies, testbeds and 
trials, and protocols will elicit particular attention.

The workshop solicits papers addressing the following topics:

    Smart Communications for Cloud Computing and Internet of things
    Architecture and protocol for wireless based sensor networks
    Vehicular applications of autonomous behavior
    Underwater applications
    Rural applications
    Autonomous manipulation using service robots
    Virtual networks and distributed Agent Platform
    Pervasive communication in autonomous application fields
    Rehabilitation robotics, exoskeletons, smart textile clothes and
 wearable robots applications
    Context-awareness and ubiquitous robotics
    Secure, scalable and low cost network paradigms applications
    Techniques of sensing, actuation and recognition
    Vehicular applications of autonomous behavior
    Underwater applications
    Rural applications
    Design modeling and control of autonomous robotic systems
    Assistive robotic technology
    Energy optimization of autonomous systems
    Monitoring and security of autonomous systems in intelligent environment
    Context awareness using sensor networks
    Network based transmission architecture for controlling autonomous systems
    Real-time network based structure using sensors, actuators and transducers

All

 submitted papers will be rigorously reviewed and we will select papers 
based on their originality, timeliness, significance, and relevance to 
the workshop. All accepted papers must be presented and at least on 
author needs to register for the paper to be included in the workshop 
proceedings. Submitted papers should not be under consideration for 
publication anywhere else.
==


Best regards,



Nadeem Javaid, Ph.D. Wireless Networks (University of Paris-Est, France),
Assistant Professor, Dept. of Electrical Engineering,
COMSATS Institute of IT, Park Road, Chak-Shahzad, 44000, Islamabad, Pakistan.
nadeemjav...@comsats.edu.pk/@ieee.org/@yahoo.com,
Office#: +92 (0)51 9049207,Mobile#: +92 (0)300 5792728.
http://ww3.comsats.edu.pk/faculty/FacultyDetails.aspx?Uid=1211___

[Discuss-gnuradio] USRP2 / Tunnel.py packet reflection issue

[David Barton]

 
I have been troubleshooting an issue with possible packet relflections and 
cannot figure out the cause. I am running tunnel.py on two USRP2s that are 
cabled together with a 20dB attenuator between them. The settings I am using on 
both sides for tunnel.py are:
 
Tx Gain: 15 dB
Rx Gain: 10 dB
Carrier Threshold: -80
Rx Tunnel Freq: 400 MHz
Modulation: GMSK
Bit Rate: 1Mb/sec
 
When I use VLC to stream a video from computer A to computer B  over the USRP 
link it works ok but there are alot of reflected packs being recorded by 
computer A. The same thing happens when I try to stream from computer A to 
computer B. This also occurs when I use iperf to test the link. Strangely, 
though there are NO reflected packets when I ping between the computers.
 
Below is a paste of some of the output from computer A. I put in a timestamp on 
the left of when events occur. I also put in an explicit statement to print out 
when tunnel is backing off and for how long. I added sequence number to make it 
blatantly obvious that the computer is receiving its own packet. Any packet 
with a sequence number beginning originates from computer A. If the packet 
originated from computer B it shows up at RX_packet=none. As it shows computer 
A is receiving its own packets!
[ 63.61 ] Tx: seq_no = 100054 | len(payload) = 1448
[ 63.61 ] Tx: seq_no = 100055 | len(payload) = 186
[ 63.61 ] Tx: seq_no = 100056 | len(payload) = 1310
[ 63.61 ] Tx: seq_no = 100057 | len(payload) = 1448
[ 63.61 ] Tx: seq_no = 100058 | len(payload) = 1021
[ 63.61 ] Backing off for 0.001 sec 
[ 63.62 ] Backing off for 0.002 sec 
[ 63.62 ] Backing off for 0.004 sec 
[ 63.63 ] Backing off for 0.008 sec 
[ 63.64 ] Backing off for 0.016 sec 
[ 63.64 ] Rx: ok = True | seq_no = 100054 | len(payload) = 1448
[ 63.66 ] Backing off for 0.032 sec 
[ 63.64 ] Rx: ok = True | seq_no = 100055 | len(payload) = 186
[ 63.66 ] Rx: ok = True | seq_no = 100056 | len(payload) = 1310
[ 63.66 ] Rx: ok = True | seq_no = 100057 | len(payload) = 1448
[ 63.67 ] Backing off for 0.064 sec 
[ 63.67 ] Rx: ok = True | seq_no = 100058 | len(payload) = 1021
[ 63.72 ] Tx: seq_no = 100059 | len(payload) = 1448
[ 63.72 ] Tx: seq_no = 100060 | len(payload) = 70
[ 63.72 ] Tx: seq_no = 100061 | len(payload) = 1448
[ 63.72 ] Tx: seq_no = 100062 | len(payload) = 150
[ 63.72 ] Tx: seq_no = 100063 | len(payload) = 1448
[ 63.72 ] Tx: seq_no = 100064 | len(payload) = 248
[ 63.72 ] Backing off for 0.001 sec 
[ 63.72 ] Backing off for 0.002 sec 
[ 63.73 ] Backing off for 0.004 sec 
[ 63.74 ] Backing off for 0.008 sec 
[ 63.75 ] Backing off for 0.016 sec 
[ 63.74 ] Rx: ok = True | seq_no = 100060 | len(payload) = 70
[ 63.75 ] Rx: ok = True | seq_no = 100061 | len(payload) = 1448
[ 63.76 ] Backing off for 0.032 sec 
[ 63.75 ] Rx: ok = True | seq_no = 100062 | len(payload) = 150
[ 63.76 ] Rx: ok = True | seq_no = 100063 | len(payload) = 1448
[ 63.76 ] Rx: ok = True | seq_no = 100064 | len(payload) = 248
[ 63.78 ] Tx: seq_no = 100065 | len(payload) = 1448
[ 63.78 ] Tx: seq_no = 100066 | len(payload) = 566
[ 63.78 ] Tx: seq_no = 100067 | len(payload) = 1448
[ 63.78 ] Tx: seq_no = 100068 | len(payload) = 987
[ 63.78 ] Backing off for 0.001 sec 
[ 63.79 ] Backing off for 0.002 sec 
[ 63.79 ] Backing off for 0.004 sec 
[ 63.79 ] Backing off for 0.008 sec 
[ 63.8 ] Backing off for 0.016 sec 
[ 63.8 ] Rx: ok = True | seq_no = 100066 | len(payload) = 566
[ 63.82 ] Backing off for 0.032 sec 
[ 63.82 ] Rx: ok = True | seq_no = 100067 | len(payload) = 1448
[ 63.82 ] Rx: ok = True | seq_no = 100068 | len(payload) = 987
[ 63.84 ] Tx: seq_no = 100069 | len(payload) = 1448
[ 63.84 ] Tx: seq_no = 100070 | len(payload) = 1448
[ 63.84 ] Tx: seq_no = 100071 | len(payload) = 1448
[ 63.84 ] Tx: seq_no = 100072 | len(payload) = 321
[ 63.84 ] Tx: seq_no = 100073 | len(payload) = 1448
[ 63.84 ] Tx: seq_no = 100074 | len(payload) = 855
[ 63.84 ] Backing off for 0.001 sec 
[ 63.84 ] Backing off for 0.002 sec 
[ 63.85 ] Backing off for 0.004 sec 
[ 63.85 ] Backing off for 0.008 sec 
[ 63.86 ] Backing off for 0.016 sec 
[ 63.87 ] Backing off for 0.032 sec 
[ 63.86 ] Rx: ok = True | seq_no = 100070 | len(payload) = 1448
[ 63.89 ] Rx: ok = True | seq_no = 100071 | len(payload) = 1448
[ 63.89 ] Rx: ok = True | seq_no = 100072 | len(payload) = 321
[ 63.89 ] Rx: ok = True | seq_no = 100073 | len(payload) = 1448
[ 63.9 ] Backing off for 0.064 sec 
[ 63.9 ] Rx: ok = True | seq_no = 100074 | len(payload) = 855

 
 Does anyone have any idea why this could be occurring? I thought maybe it 
would be a physical reflection but dont understand why ping packets would not 
be reflected in that case. 
 
Thanks,
Dave___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] New build structure! (Warning #2)

[Josh Blum]

On 10/20/2011 04:19 AM, Paul M. Bendixen wrote:
> Hi happy to hear it, autotools were complaining about old syntax on my
> machine
> 
> Using gentoo (not too heavily updated I'm afraid) and not succeding
> 
> Configuring using cmake went well, but compiling didn't, already at first
> stop volk (that I'm not entirely sure i need) a _lot_ of errors occured.
> To be more specific, more than my shell history could take.
> 

Hmm. thats not expected; volk should compile perfectly. Try to
completely clean the source tree before building w/ cmake. git clean
-dfx If you still see the errors can you dump to a file and post them?

Also, cmake -DENABLE_VOLK=OFF  will disable it.

-josh

> 
> 
> 2011/10/20 Tom Rondeau 
> 
>> [snip]
>> $ cd gnuradio
>> $ git checkout next
>> $ git pull
>> $ mkdir build
>> $ cd build
>> $ cmake ../
>>
> Up to here it went well
> 
>> $ make
>>
> This fails already at volk
> 
>> $ make test
>> $ sudo make install
>>
>> Is there any way to disable parts such as volk? (akin to --disable-volk
> that doesn't seem to work)
> 
> The errors seems to be syntax errors in volk. Errors include:
> 
> "In file included from
> /home/expert/skole/speciale/GnuRadio/git/build/volk/lib/volk.c:6:
> /home/expert/skole/speciale/GnuRadio/git/build/volk/lib/volk_machines.h:20:
> fejl: expected ':', ',', ';', '}' or '__attribute__' before
> 'volk_16i_branch_4_state_8_a_archs'
> " (the first one, fejl means error in danish)
> 
> Any other outputs I can provide to help, just ask.
> 
> 
> 
>> Again, if that fails but you really need to use the current next branch,
>> the same autotools build process will work. Please let us know if you find
>> any issues.
>>
>> Thanks, I'll just checkout master again ;)
> 
> Best
> Paul M. Bendixen
> 
> * - - */* -/* * -/* - * */- * * */*/- */- * */* */- * * -/*/- */* - - *- */-
> - */- -/* -/* */* - * */* - * - * -/- * - */- - -/- -//
> 
> 
> 
> 
> ___
> 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] New build structure! (Warning #2)

[Paul M. Bendixen]

2011/10/20 Josh Blum 

>
>
> On 10/20/2011 04:19 AM, Paul M. Bendixen wrote:
> > Hi happy to hear it, autotools were complaining about old syntax on my
> > machine
> >
> > Using gentoo (not too heavily updated I'm afraid) and not succeding
> >
> > Configuring using cmake went well, but compiling didn't, already at first
> > stop volk (that I'm not entirely sure i need) a _lot_ of errors occured.
> > To be more specific, more than my shell history could take.
> >
>
>

Hmm. thats not expected; volk should compile perfectly. Try to

 completely clean the source tree before building w/ cmake. git clean

 -dfx If you still see the errors can you dump to a file and post them
>

Volk usually also fails on the old install, the problem is , I think it
should detect that it was no good and take it out of the build entirely?


> Also, cmake -DENABLE_VOLK=OFF  will disable it.
>
> Yeah, found that when i posted the output of cmake to a file and read it,
could there be some more intuitive way of finding this out than
trial-and-error?
I think the configurescript should bypass the volk entirely when it cannot
build it?

Cmake wrote out the following
-- Configuring volk support...
-- Enabling volk support.
-- Override with -DENABLE_VOLK=ON/OFF
-- Available arches:
generic;3dnow;popcount;mmx;sse;sse2;orc;sse3;ssse3;sse4_a;sse4_1;sse4_2
-- Available machines:
generic;sse2_only;sse2_32;sse3_32;ssse3_32;sse4_a_32;sse4_1_32;sse4_2_32
-- checking for module 'orc-0.4 > 0.4.11'
-- package 'orc-0.4 > 0.4.11' not found
-- Did not find liborc and orcc, disabling orc support...
-- Using install prefix: /usr/local
-- 

Also, because i use gentoo, I earlier had to give the QWT dir in order for
gnuradio to build gr-qtgui, the cmake now writes:
-- Could NOT find Qwt (missing: QWT_INCLUDE_DIRS)
...
-- Configuring gr-qtgui support...
-- Dependency Boost_FOUND = TRUE
-- Dependency QT4_FOUND = YES
-- Dependency QWT_FOUND = FALSE
-- Dependency ENABLE_GR_CORE = ON
-- Dependency PYTHONLIBS_FOUND = TRUE
-- Dependency PYQT4_FOUND = TRUE
-- Disabling gr-qtgui support.
-- Override with -DENABLE_GR_QTGUI=ON/OFF

Seeing as i have qwt in version 5.2.0 I find this weird.
(I do not however have pyqwt (it is masked in gentoo), could this be the
actual error?)

Anyways, the make test works now, I'm not going to test make install in
order to maintain compatibility with the environment we are doing our thesis
on, but everything looks fine.

Best

Paul

>

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

Re: [Discuss-gnuradio] USRP2 / Tunnel.py packet reflection issue

[Marcus D. Leech]

On 20/10/2011 10:25 AM, David Barton wrote:
I have been troubleshooting an issue with possible packet relflections 
and cannot figure out the cause. I am running tunnel.py on two USRP2s 
that are cabled together with a 20dB attenuator between them. The 
settings I am using on both sides for tunnel.py are:

Tx Gain: 15 dB
Rx Gain: 10 dB
Carrier Threshold: -80
Rx Tunnel Freq: 400 MHz
Modulation: GMSK
Bit Rate: 1Mb/sec
When I use VLC to stream a video from computer A to computer B  over 
the USRP link it works ok but there are alot of reflected packs being 
recorded by computer A. The same thing happens when I try to stream 
from computer A to computer B. This also occurs when I use iperf to 
test the link. Strangely, though there are NO reflected packets when I 
ping between the computers.
Below is a paste of some of the output from computer A. I put in a 
timestamp on the left of when events occur. I also put in an explicit 
statement to print out when tunnel is backing off and for how long. I 
added sequence number to make it blatantly obvious that the computer 
is receiving its own packet. Any packet with a sequence number 
beginning originates from computer A. If the packet originated from 
computer B it shows up at RX_packet=none. As it shows computer A is 
receiving its own packets!

[ 63.61 ] Tx: seq_no = 100054 | len(payload) = 1448
[ 63.61 ] Tx: seq_no = 100055 | len(payload) = 186
[ 63.61 ] Tx: seq_no = 100056 | len(payload) = 1310
[ 63.61 ] Tx: seq_no = 100057 | len(payload) = 1448
[ 63.61 ] Tx: seq_no = 100058 | len(payload) = 1021
[ 63.61 ] Backing off for 0.001 sec
[ 63.62 ] Backing off for 0.002 sec
[ 63.62 ] Backing off for 0.004 sec
[ 63.63 ] Backing off for 0.008 sec
[ 63.64 ] Backing off for 0.016 sec
[ 63.64 ] Rx: ok = True | seq_no = 100054 | len(payload) = 1448
[ 63.66 ] Backing off for 0.032 sec
[ 63.64 ] Rx: ok = True | seq_no = 100055 | len(payload) = 186
[ 63.66 ] Rx: ok = True | seq_no = 100056 | len(payload) = 1310
[ 63.66 ] Rx: ok = True | seq_no = 100057 | len(payload) = 1448
[ 63.67 ] Backing off for 0.064 sec
[ 63.67 ] Rx: ok = True | seq_no = 100058 | len(payload) = 1021
[ 63.72 ] Tx: seq_no = 100059 | len(payload) = 1448
[ 63.72 ] Tx: seq_no = 100060 | len(payload) = 70
[ 63.72 ] Tx: seq_no = 100061 | len(payload) = 1448
[ 63.72 ] Tx: seq_no = 100062 | len(payload) = 150
[ 63.72 ] Tx: seq_no = 100063 | len(payload) = 1448
[ 63.72 ] Tx: seq_no = 100064 | len(payload) = 248
[ 63.72 ] Backing off for 0.001 sec
[ 63.72 ] Backing off for 0.002 sec
[ 63.73 ] Backing off for 0.004 sec
[ 63.74 ] Backing off for 0.008 sec
[ 63.75 ] Backing off for 0.016 sec
[ 63.74 ] Rx: ok = True | seq_no = 100060 | len(payload) = 70
[ 63.75 ] Rx: ok = True | seq_no = 100061 | len(payload) = 1448
[ 63.76 ] Backing off for 0.032 sec
[ 63.75 ] Rx: ok = True | seq_no = 100062 | len(payload) = 150
[ 63.76 ] Rx: ok = True | seq_no = 100063 | len(payload) = 1448
[ 63.76 ] Rx: ok = True | seq_no = 100064 | len(payload) = 248
[ 63.78 ] Tx: seq_no = 100065 | len(payload) = 1448
[ 63.78 ] Tx: seq_no = 100066 | len(payload) = 566
[ 63.78 ] Tx: seq_no = 100067 | len(payload) = 1448
[ 63.78 ] Tx: seq_no = 100068 | len(payload) = 987
[ 63.78 ] Backing off for 0.001 sec
[ 63.79 ] Backing off for 0.002 sec
[ 63.79 ] Backing off for 0.004 sec
[ 63.79 ] Backing off for 0.008 sec
[ 63.8 ] Backing off for 0.016 sec
[ 63.8 ] Rx: ok = True | seq_no = 100066 | len(payload) = 566
[ 63.82 ] Backing off for 0.032 sec
[ 63.82 ] Rx: ok = True | seq_no = 100067 | len(payload) = 1448
[ 63.82 ] Rx: ok = True | seq_no = 100068 | len(payload) = 987
[ 63.84 ] Tx: seq_no = 100069 | len(payload) = 1448
[ 63.84 ] Tx: seq_no = 100070 | len(payload) = 1448
[ 63.84 ] Tx: seq_no = 100071 | len(payload) = 1448
[ 63.84 ] Tx: seq_no = 100072 | len(payload) = 321
[ 63.84 ] Tx: seq_no = 100073 | len(payload) = 1448
[ 63.84 ] Tx: seq_no = 100074 | len(payload) = 855
[ 63.84 ] Backing off for 0.001 sec
[ 63.84 ] Backing off for 0.002 sec
[ 63.85 ] Backing off for 0.004 sec
[ 63.85 ] Backing off for 0.008 sec
[ 63.86 ] Backing off for 0.016 sec
[ 63.87 ] Backing off for 0.032 sec
[ 63.86 ] Rx: ok = True | seq_no = 100070 | len(payload) = 1448
[ 63.89 ] Rx: ok = True | seq_no = 100071 | len(payload) = 1448
[ 63.89 ] Rx: ok = True | seq_no = 100072 | len(payload) = 321
[ 63.89 ] Rx: ok = True | seq_no = 100073 | len(payload) = 1448
[ 63.9 ] Backing off for 0.064 sec
[ 63.9 ] Rx: ok = True | seq_no = 100074 | len(payload) = 855
 Does anyone have any idea why this could be occurring? I thought 
maybe it would be a physical reflection but dont understand why ping 
packets would not be reflected in that case.

Thanks,
Dave
There's generally only about 45dB of isolation available between TX and 
RX, so if you're running in full-duplex, your receiver will see its

  own transmissions.



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

Re: [Discuss-gnuradio] New build structure! (Warning #2)

[Josh Blum]

> 
> Volk usually also fails on the old install, the problem is , I think it
> should detect that it was no good and take it out of the build entirely?
> 

No, this is a bug that needs to be fixed. Please help. Provide compiler
version gcc --version and all error verbose. Thanks.

> 
>> Also, cmake -DENABLE_VOLK=OFF  will disable it.
>>
>> Yeah, found that when i posted the output of cmake to a file and read it,
> could there be some more intuitive way of finding this out than
> trial-and-error?

cmake-gui, ccmake (ncurses) would make it more obvious. Also future
documentation. :-)

> I think the configurescript should bypass the volk entirely when it cannot
> build it?
> 

How can the configure know that volk cannot be built?

-Josh

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

Re: [Discuss-gnuradio] New build structure! (Warning #2)

[Tom Rondeau]

On Thu, Oct 20, 2011 at 8:29 AM, Josh Blum  wrote:

>
> >
> > Volk usually also fails on the old install, the problem is , I think it
> > should detect that it was no good and take it out of the build entirely?
> >
>
> No, this is a bug that needs to be fixed. Please help. Provide compiler
> version gcc --version and all error verbose. Thanks.
>
> >
> >> Also, cmake -DENABLE_VOLK=OFF  will disable it.
> >>
> >> Yeah, found that when i posted the output of cmake to a file and read
> it,
> > could there be some more intuitive way of finding this out than
> > trial-and-error?
>
> cmake-gui, ccmake (ncurses) would make it more obvious. Also future
> documentation. :-)
>
> > I think the configurescript should bypass the volk entirely when it
> cannot
> > build it?
> >
>
> How can the configure know that volk cannot be built?
>
> -Josh



Just reiterating what Josh said. We would love for the configuration process
to know that your machine can't build Volk, but it has no way of knowing
that. If your machine meets the dependencies, it will try to build it. Help
us figure out why with a full error log.

Volk will have to be built, so turning it off isn't really going to be an
option. We will be using volk inside gnuradio-core blocks as soon as we can.
Once we've done that, you will need Volk to build or you won't be able to
compile gnuradio-core. Again, help us figure out what's going wrong on your
machine so we can get it to work.

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

Re: [Discuss-gnuradio] Warning! Warning!

[Tom Rondeau]

On Thu, Oct 20, 2011 at 5:23 AM, Philip Balister wrote:

> On 10/20/2011 07:57 AM, Rafael Diniz wrote:
> > Morning people,
> > Is there any web interface where we can see the git changes?
>
> http://gnuradio.org/cgit/gnuradio.git/
>
> I find cloning the git repo and using qgit gives a much clearer picture
> of how the branches work though.
>
> Philip


And I use gitg to the same effect. These tools are very helpful in looking
at the changes being made.

However, those show you individual commits, which there are many of, and not
everyone wants that kind of detail. I have been keeping a ChangeLog (of
sorts) on gnuradio.org under "API and Code Version
Changes"
(http://gnuradio.org/redmine/projects/gnuradio/wiki/ChangeSets) to provide a
summary description of what changes are being made in the new versions.

Tom


>
> > Best regards,
> > Rafael Diniz
> >
> >> We are REMOVING the USRP and USRP2 components from GNU Radio!
> >>
> >> It's been mentioned in the past, but the change on the next branch
> >> is imminent. As of GNU Radio 3.5, we will no longer support libusrp,
> >> libusrp2 or the GNU Radio interfaces, gr-usrp and gr-usrp2. Everything
> is
> >> moving to using UHD.
> >>
> >> If you have not started to port your code over to using the UHD driver,
> >> start thinking about it now. Follow the changes that were made in 'next'
> >> to
> >> convert the old examples that used to use the gr-usrp/usrp2 interfaces
> to
> >> gr-uhd.
> >>
> >> This also reduces the number of dependencies required. Updates on this
> >> will
> >> be posted on the wiki when it becomes the stable release.
> >>
> >> Tom
> >
> >
> >
> > ___
> > 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
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Warning! Warning!

[Mark Cetilia]

What does this mean in terms of using older non-UHD-native daughterboards such 
as the DBSRX & BasicRX?
To be honest, I haven't checked into the UHD driver, since the daughterboards I 
have been working fine without it…

Best,
Mark

--
mark.cetilia.org | mem1.com | reduxproject.com

On Oct 19, 2011, at 5:58 PM, Tom Rondeau wrote:

> We are REMOVING the USRP and USRP2 components from GNU Radio!
> 
> It's been mentioned in the past, but the change on the next branch is 
> imminent. As of GNU Radio 3.5, we will no longer support libusrp, libusrp2 or 
> the GNU Radio interfaces, gr-usrp and gr-usrp2. Everything is moving to using 
> UHD.
> 
> If you have not started to port your code over to using the UHD driver, start 
> thinking about it now. Follow the changes that were made in 'next' to convert 
> the old examples that used to use the gr-usrp/usrp2 interfaces to gr-uhd.
> 
> This also reduces the number of dependencies required. Updates on this will 
> be posted on the wiki when it becomes the stable release.
> 
> Tom
> 
> ___
> 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] New build structure! (Warning #2)

[Dan CaJacob]

On 10/20/2011 09:00 AM, Martin Braun wrote:

One thing that doesn't work perfect here: I always have to run
'ldconfig' after installation. Couldn't that be part of 'make install'
(or am I the only one who has this problem?).
I had the same problem.  But after runnin it and setting the PYTHONPATH, 
everything was fine.


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

Re: [Discuss-gnuradio] fan replacement for usrp1?

[Mark Cetilia]

Thanks Robert,
I hadn't ever noticed it getting hot to the touch,
but I haven't tried running it w/ no fan & top on either…

Best,
Mark

--
mark.cetilia.org | mem1.com | reduxproject.com

On Oct 19, 2011, at 10:40 AM, Robert McGwier wrote:

> Top on.  Fire up the fastest card you have (widest band signal you can 
> process) and put your finger on the FPGA.  It is cool.
> 
> If the oscillator in the USRP1 were most stable and accurate,  it might make 
> some sense but it just doesn't in my opinion make sense so I disconnected 
> them all in my USRP 1's.
> 
> Bob
> 
> 
> On Tue, Oct 18, 2011 at 11:39 PM, Mark Cetilia  wrote:
> Ah good, glad to hear it's not just me…
> Do you run it with the top on or leave it open?
> 
> Cheers,
> Mark
> 
> --
> mark.cetilia.org | mem1.com | reduxproject.com
> 
> On Oct 18, 2011, at 11:02 PM, Robert McGwier wrote:
> 
>> Yes I have.  I disconnected it.  In my opinion, it is overkill for anything 
>> going on in a USRP1.
>> 
>> YMMV,
>> Bob
>> 
>> 
>> On Sun, Oct 9, 2011 at 1:43 AM, Mark Cetilia  wrote:
>> wondering if anybody out there has replaced their usrp1 fan with something a 
>> bit quieter?
>> i find myself listening to its incessant whine many hours a day, and it's 
>> starting to make me a little crazy—
>> especially when i am trying to listen to subtle details… anybody have a 
>> suggestion for a decent replacement?
>> 
>> cheers,
>> mark
>> 
>> --
>> mark.cetilia.org | mem1.com | reduxproject.com
>> 
>> 
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> 
>> 
>> 
>> -- 
>> Bob McGwier
>> Facebook: N4HYBob
>> ARS: N4HY
>> 
>> 
> 
> 
> 
> 
> -- 
> Bob McGwier
> Facebook: N4HYBob
> ARS: N4HY
> 
> 

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

Re: [Discuss-gnuradio] New build structure! (Warning #2)

[Marcus D. Leech]

On 20/10/2011 11:59 AM, Dan CaJacob wrote:

On 10/20/2011 09:00 AM, Martin Braun wrote:

One thing that doesn't work perfect here: I always have to run
'ldconfig' after installation. Couldn't that be part of 'make install'
(or am I the only one who has this problem?).
I had the same problem.  But after runnin it and setting the 
PYTHONPATH, everything was fine.



The build-gnuradio script takes care of running ldconfig



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

Re: [Discuss-gnuradio] New build structure! (Warning #2)

[Dan CaJacob]

On 10/20/2011 12:02 PM, Marcus D. Leech wrote:

On 20/10/2011 11:59 AM, Dan CaJacob wrote:

On 10/20/2011 09:00 AM, Martin Braun wrote:

One thing that doesn't work perfect here: I always have to run
'ldconfig' after installation. Couldn't that be part of 'make install'
(or am I the only one who has this problem?).
I had the same problem.  But after runnin it and setting the 
PYTHONPATH, everything was fine.



The build-gnuradio script takes care of running ldconfig
Right.  I actually used individual functions of your script to cleanup 
my install.  I was testing the cmake build, though and I don't think 
that is integrated into build-gnuradio yet.  I love your script though!


In the future, I imagine that cmake will make it possible to easily 
create deb and other binary packages that will install everything and do 
all of the extra steps necessary to get things going (like running 
ldconfig).


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

[Discuss-gnuradio] Why USRP1 cannot achieve 16 MS/s in tx?

[Mattia Rizzi]

I see that there’s a firmware to achieve 16 MS/s 8-bit in RX, why there’s no 
image for TX?
Thanks.___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] New build structure! (Warning #2)

[Ben Hilburn]

>
> Also, because i use gentoo, I earlier had to give the QWT dir in order for
> gnuradio to build gr-qtgui, the cmake now writes:
> -- Could NOT find Qwt (missing: QWT_INCLUDE_DIRS)
> ...
> -- Configuring gr-qtgui support...
> -- Dependency Boost_FOUND = TRUE
> -- Dependency QT4_FOUND = YES
> -- Dependency QWT_FOUND = FALSE
> -- Dependency ENABLE_GR_CORE = ON
> -- Dependency PYTHONLIBS_FOUND = TRUE
> -- Dependency PYQT4_FOUND = TRUE
> -- Disabling gr-qtgui support.
> -- Override with -DENABLE_GR_QTGUI=ON/OFF
>
> Seeing as i have qwt in version 5.2.0 I find this weird.
> (I do not however have pyqwt (it is masked in gentoo), could this be the
> actual error?)
>

Paul -

I run Arch Linux, and have similar troubles with QWT.  One of the main
issues is that QWT is not bundled in a way that makes it easy to work with
(it lacks a package-config file, etc.,) - which makes it hard for build
toolchains to find it consistently on all Linux OSes.  As a result, I almost
always have to manually pass in the location of QWT.

Anyway, you mentioned that you used to pass it in manually.  Did you try
doing that here, by adding your QWT install directory to CMake's search
path?

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

Re: [Discuss-gnuradio] Warning! Warning!

[Tom Rondeau]

On Thu, Oct 20, 2011 at 8:58 AM, Mark Cetilia  wrote:

> What does this mean in terms of using older non-UHD-native daughterboards
> such as the DBSRX & BasicRX?
> To be honest, I haven't checked into the UHD driver, since the
> daughterboards I have been working fine without it…
>
> Best,
> Mark



All USRP daughterboards are supported in UHD. You should have no problems
with DBSRX and BasicRX.

Tom



 --
> mark.cetilia.org | mem1.com | reduxproject.com
>
> On Oct 19, 2011, at 5:58 PM, Tom Rondeau wrote:
>
> > We are REMOVING the USRP and USRP2 components from GNU Radio!
> >
> > It's been mentioned in the past, but the change on the next branch is
> imminent. As of GNU Radio 3.5, we will no longer support libusrp, libusrp2
> or the GNU Radio interfaces, gr-usrp and gr-usrp2. Everything is moving to
> using UHD.
> >
> > If you have not started to port your code over to using the UHD driver,
> start thinking about it now. Follow the changes that were made in 'next' to
> convert the old examples that used to use the gr-usrp/usrp2 interfaces to
> gr-uhd.
> >
> > This also reduces the number of dependencies required. Updates on this
> will be posted on the wiki when it becomes the stable release.
> >
> > Tom
> >
> > ___
> > 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] Fwd: volk build error

[Tom Rondeau]

On Wed, Oct 19, 2011 at 8:22 PM, Stevie  wrote:

> Hi,
>
> I'm experiencing problems with volk when building on an amd64 Debian
> "testing". It started when volk was first introduced to the git tree and is
> also my experience with the 3.4 release. When I build I get the following:
>
> make[4]: Entering directory `/home/stevie/SourceCode/gnuradio/volk/lib'
> /bin/bash ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I.
> -I..  -I../include -I../lib -I/usr/include  -I../include -I../gen/include
> -Dvolk_EXPORTS -fvisibility=hidden -DLV_MACHINE_SSE3_64
> -DLV_MACHINE_GENERIC  -DLV_MACHINE_SSE2_64  -DLV_MACHINE_SSE2_ONLY
>  -DLV_MACHINE_SSE4_1_64   -DLV_MACHINE_SSSE3_64-g -O2 -MT
> libvolk_la-volk.lo -MD -MP -MF .deps/libvolk_la-volk.Tpo -c -o
> libvolk_la-volk.lo `test -f '../gen/lib/volk.c' || echo
> './'`../gen/lib/volk.c
> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I../lib
> -I/usr/include -I../include -I../gen/include -Dvolk_EXPORTS
> -fvisibility=hidden -DLV_MACHINE_SSE3_64 -DLV_MACHINE_GENERIC
> -DLV_MACHINE_SSE2_64 -DLV_MACHINE_SSE2_ONLY -DLV_MACHINE_SSE4_1_64
> -DLV_MACHINE_SSSE3_64 -g -O2 -MT libvolk_la-volk.lo -MD -MP -MF
> .deps/libvolk_la-volk.Tpo -c ../gen/lib/volk.c  -fPIC -DPIC -o
> .libs/libvolk_la-volk.o
> In file included from ../gen/lib/volk.c:6:0:
> ../gen/lib/volk_machines.h:20:5: error: unknown type name
> 'p_16i_x5_add_quad_16i_x4_a'
> ../gen/lib/volk_machines.h:25:5: error: unknown type name
> 'p_16i_branch_4_state_8_a'
> ../gen/lib/volk_machines.h:30:5: error: unknown type name
> 'p_16ic_deinterleave_16i_x2_a'
> ../gen/lib/volk_machines.h:35:5: error: unknown type name
> 'p_16ic_s32f_deinterleave_32f_x2_a'
> ../gen/lib/volk_machines.h:40:5: error: unknown type name
> 'p_16ic_deinterleave_real_16i_a'
> ../gen/lib/volk_machines.h:45:5: error: unknown type name
> 'p_16ic_s32f_deinterleave_real_32f_a'
> ../gen/lib/volk_machines.h:50:5: error: unknown type name
> 'p_16ic_deinterleave_real_8i_a'
> ../gen/lib/volk_machines.h:55:5: error: unknown type name
> 'p_16ic_magnitude_16i_a'
> ../gen/lib/volk_machines.h:60:5: error: unknown type name
> 'p_16ic_s32f_magnitude_32f_a'
> ../gen/lib/volk_machines.h:65:5: error: unknown type name
> 'p_16i_s32f_convert_32f_a'
> ../gen/lib/volk_machines.h:75:5: error: unknown type name
> 'p_16i_convert_8i_a'
> ../gen/lib/volk_machines.h:85:5: error: unknown type name
> 'p_16i_max_star_16i_a'
> ../gen/lib/volk_machines.h:90:5: error: unknown type name
> 'p_16i_max_star_horizontal_16i_a'
> ../gen/lib/volk_machines.h:95:5: error: unknown type name
> 'p_16i_permute_and_scalar_add_a'
> ../gen/lib/volk_machines.h:100:5: error: unknown type name
> 'p_16i_x4_quad_max_star_16i_a'
> ../gen/lib/volk_machines.h:105:5: error: unknown type name
> 'p_16u_byteswap_a'
> ...
>
> and so on for a huge list of unknown types and then lots of errors later on
> because these types haven't been defined.
>
> ATB
>
> Stevie
>

Those typedefs are part of volk, so it's like your machine isn't finding the
volk header files. It's possible something happened incorrectly with
bootstrap or configure (it looks like you're running the autotools stuff).

Could you send the full output of configure?

Also, have you tried building GNU Radio and volk using the new cmake build
in the 'next' branch?

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

Re: [Discuss-gnuradio] Warning! Warning!

[Marcus D. Leech]

On 20/10/2011 11:58 AM, Mark Cetilia wrote:

What does this mean in terms of using older non-UHD-native daughterboards such as 
the DBSRX&  BasicRX?
To be honest, I haven't checked into the UHD driver, since the daughterboards I 
have been working fine without it…

Best,
Mark


UHD supports ALL of the previous daughtercards, even ones that are no 
longer in production and pre-date UHD.



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

Re: [Discuss-gnuradio] New build structure! (Warning #2)

[Alexandru Csete]

On Thu, Oct 20, 2011 at 6:51 AM, Josh Blum  wrote:
>
>
> On 10/19/2011 08:42 PM, Dan CaJacob wrote:
>> On 10/19/2011 09:43 PM, Tom Rondeau wrote:
>>> ... we need people to start using it and testing as much as possible.
>> Build went smoothly with cmake on Ubuntu 11.10 x64  Unfortunately, it
>> built as 32 bit, but it works.  I usually build with Marcus Leech's
>> script which handles the architecture automatically.  I assume I could
>> have given it a proper flag to build as 64 bit?  Basically it installed
>> to /usr/local/lib/... instead of /usr/local/lib64/...
>>
>
> lib64 is a redhat thing, so that should be correct for ubuntu
>

Actually, it's also used in Ubuntu 11.10 now. I just built UHD and GNU
Radio yesterday. UHD installed in lib/ while GNU Radio (using
autotools) went to lib64/

Alex

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

[Discuss-gnuradio] Error configuring with cmake on USRP-E100

[Philip Balister]

I just got this trying to build gnuradio/next with cmake on an e100:

-- Performing Test HAVE_SINF
-- Performing Test HAVE_SINF - Success
-- Performing Test HAVE_COSF
-- Performing Test HAVE_COSF - Success
-- Performing Test HAVE_MMAP
-- Performing Test HAVE_MMAP - Success
CMake Warning at gnuradio-core/src/lib/filter/CMakeLists.txt:169 (if):
  given arguments:

"CMAKE_SYSTEM_PROCESSOR_x86" "AND" "EQUAL" "64"

  Unknown arguments specified
Call Stack (most recent call first):
  cmake/Modules/GrMiscUtils.cmake:77 (include)
  gnuradio-core/src/lib/CMakeLists.txt:30 (GR_INCLUDE_SUBDIRECTORY)


CMake Error at gnuradio-core/src/lib/filter/CMakeLists.txt:183 (elseif):
  given arguments:

"CMAKE_SYSTEM_PROCESSOR_x86" "AND" "EQUAL" "32"

  Unknown arguments specified
Call Stack (most recent call first):
  cmake/Modules/GrMiscUtils.cmake:77 (include)
  gnuradio-core/src/lib/CMakeLists.txt:30 (GR_INCLUDE_SUBDIRECTORY)


-- Configuring incomplete, errors occurred!
root@usrp-e1xx:~/gnuradio/build#


Philip

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

Re: [Discuss-gnuradio] Error configuring with cmake on USRP-E100

[Josh Blum]

On 10/20/2011 10:51 AM, Philip Balister wrote:
> I just got this trying to build gnuradio/next with cmake on an e100:
> 
> -- Performing Test HAVE_SINF
> -- Performing Test HAVE_SINF - Success
> -- Performing Test HAVE_COSF
> -- Performing Test HAVE_COSF - Success
> -- Performing Test HAVE_MMAP
> -- Performing Test HAVE_MMAP - Success
> CMake Warning at gnuradio-core/src/lib/filter/CMakeLists.txt:169 (if):
>   given arguments:
> 
> "CMAKE_SYSTEM_PROCESSOR_x86" "AND" "EQUAL" "64"
> 
>   Unknown arguments specified
> Call Stack (most recent call first):
>   cmake/Modules/GrMiscUtils.cmake:77 (include)
>   gnuradio-core/src/lib/CMakeLists.txt:30 (GR_INCLUDE_SUBDIRECTORY)
> 
> 
> CMake Error at gnuradio-core/src/lib/filter/CMakeLists.txt:183 (elseif):
>   given arguments:
> 
> "CMAKE_SYSTEM_PROCESSOR_x86" "AND" "EQUAL" "32"
> 
>   Unknown arguments specified
> Call Stack (most recent call first):
>   cmake/Modules/GrMiscUtils.cmake:77 (include)
>   gnuradio-core/src/lib/CMakeLists.txt:30 (GR_INCLUDE_SUBDIRECTORY)
> 
> 
> -- Configuring incomplete, errors occurred!
> root@usrp-e1xx:~/gnuradio/build#
> 

I think i see why, can you diff this try?
http://pastebin.com/qvBN7mZk

_josh

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

Re: [Discuss-gnuradio] New build structure! (Warning #2)

[Josh Blum]

On 10/20/2011 10:46 AM, Alexandru Csete wrote:
> On Thu, Oct 20, 2011 at 6:51 AM, Josh Blum  wrote:
>>
>>
>> On 10/19/2011 08:42 PM, Dan CaJacob wrote:
>>> On 10/19/2011 09:43 PM, Tom Rondeau wrote:
 ... we need people to start using it and testing as much as possible.
>>> Build went smoothly with cmake on Ubuntu 11.10 x64  Unfortunately, it
>>> built as 32 bit, but it works.  I usually build with Marcus Leech's
>>> script which handles the architecture automatically.  I assume I could
>>> have given it a proper flag to build as 64 bit?  Basically it installed
>>> to /usr/local/lib/... instead of /usr/local/lib64/...
>>>
>>
>> lib64 is a redhat thing, so that should be correct for ubuntu
>>
> 
> Actually, it's also used in Ubuntu 11.10 now. I just built UHD and GNU
> Radio yesterday. UHD installed in lib/ while GNU Radio (using
> autotools) went to lib64/
> 

Not sure why gnuradio autofoo is doing that. Its only supposed to
install lib64 when /etc/redhat-release (i think) file is found and 64
bit. So something must be confused.

-josh

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

Re: [Discuss-gnuradio] New build structure! (Warning #2)

[Arturo Rinaldi]

Il 20/10/2011 03:43, Tom Rondeau ha scritto:
Another big change is happening today! Josh Blum has make GNU Radio 
build using cmake, and we are hoping to switch over to it completely. 
The 'next' branch has just pulled in his changes, and we now have 
parallel build systems, cmake and autofoo. We are trying to make cmake 
the default build system, so we need people to start using it and 
testing as much as possible. For people who have issues using cmake, 
the autofoo stuff will still be there. The parallel build system will 
be in place official from 3.5. As of 3.6, we will have made a decision 
to move to cmake or stay with autotools; the other will be removed. It 
is expected that we will move to cmake, so this is a Warning to 
everyone that autotools is being deprecated as our build method.


Details about using cmake can be found here:
http://gnuradio.org/redmine/projects/gnuradio/wiki/CMakeWork

To summarizes:

$ cd gnuradio
$ git checkout next
$ git pull
$ mkdir build
$ cd build
$ cmake ../
$ make
$ make test
$ sudo make install

Again, if that fails but you really need to use the current next 
branch, the same autotools build process will work. Please let us know 
if you find any issues.


Thanks!
Tom



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

does this mean that i could perform the steps

/mkdir build
cd build
cmake -DCPACK_GENERATOR=DEB ../
make package/

and make deb(s) of the current git release ? which is the switch to 
disable one of the components ?


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

Re: [Discuss-gnuradio] Error configuring with cmake on USRP-E100

[Philip Balister]

On 10/20/2011 02:00 PM, Josh Blum wrote:
> 
> 
> On 10/20/2011 10:51 AM, Philip Balister wrote:
>> I just got this trying to build gnuradio/next with cmake on an e100:
>>
>> -- Performing Test HAVE_SINF
>> -- Performing Test HAVE_SINF - Success
>> -- Performing Test HAVE_COSF
>> -- Performing Test HAVE_COSF - Success
>> -- Performing Test HAVE_MMAP
>> -- Performing Test HAVE_MMAP - Success
>> CMake Warning at gnuradio-core/src/lib/filter/CMakeLists.txt:169 (if):
>>   given arguments:
>>
>> "CMAKE_SYSTEM_PROCESSOR_x86" "AND" "EQUAL" "64"
>>
>>   Unknown arguments specified
>> Call Stack (most recent call first):
>>   cmake/Modules/GrMiscUtils.cmake:77 (include)
>>   gnuradio-core/src/lib/CMakeLists.txt:30 (GR_INCLUDE_SUBDIRECTORY)
>>
>>
>> CMake Error at gnuradio-core/src/lib/filter/CMakeLists.txt:183 (elseif):
>>   given arguments:
>>
>> "CMAKE_SYSTEM_PROCESSOR_x86" "AND" "EQUAL" "32"
>>
>>   Unknown arguments specified
>> Call Stack (most recent call first):
>>   cmake/Modules/GrMiscUtils.cmake:77 (include)
>>   gnuradio-core/src/lib/CMakeLists.txt:30 (GR_INCLUDE_SUBDIRECTORY)
>>
>>
>> -- Configuring incomplete, errors occurred!
>> root@usrp-e1xx:~/gnuradio/build#
>>
> 
> I think i see why, can you diff this try?
> http://pastebin.com/qvBN7mZk

That works better. On to some Qt detection issue.

Philip

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

Re: [Discuss-gnuradio] New build structure! (Warning #2)

[Josh Blum]

On 10/20/2011 09:00 AM, Paul M. Bendixen wrote:
> 2011/10/20 Josh Blum 
> 
>>
>>>
>>> Volk usually also fails on the old install, the problem is , I think it
>>> should detect that it was no good and take it out of the build entirely?
>>>
>>
>> No, this is a bug that needs to be fixed. Please help. Provide compiler
>> version gcc --version and all error verbose. Thanks.
>>
> 
> gcc --version:  gcc (Gentoo 4.3.4 p1.2, pie-10.1.5) 4.3.4
> 
> error from make is in make.log
> Furthermore stdout wrote:
> 

You need to clean your source directory. This file should not exist:
/home/expert/skole/speciale/GnuRadio/git/volk/include/volk/volk.h:7:29:
error: volk/volk_config.h: Ingen sådan fil eller filkatalog

Can you git clean -dfx and try again?

-Josh

> [ 0%] Generating ../include/volk/volk.h, volk.c, volk_init.h,
> ../include/volk/volk_typedefs.h, ../include/volk/volk_cpu.h, volk_cpu.c,
> ../include/volk/volk_config_fixed.h, volk_environment_init.c,
> volk_environment_init.h, volk_machines.h, volk_machines.c,
> volk_machine_generic.c, volk_machine_sse2_only.c, volk_machine_sse2_32.c,
> volk_machine_sse3_32.c, volk_machine_ssse3_32.c, volk_machine_sse4_a_32.c,
> volk_machine_sse4_1_32.c, volk_machine_sse4_2_32.c
> Scanning dependencies of target volk
> [ 0%] Building C object volk/lib/CMakeFiles/volk.dir/volk_prefs.c.o
> [ 0%] Building C object volk/lib/CMakeFiles/volk.dir/volk_rank_archs.c.o
> [ 0%] Building C object volk/lib/CMakeFiles/volk.dir/volk.c.o
> 
> before dying
> 
> 
>>>
 Also, cmake -DENABLE_VOLK=OFF  will disable it.

 Yeah, found that when i posted the output of cmake to a file and read
>> it,
>>> could there be some more intuitive way of finding this out than
>>> trial-and-error?
>>
> cmake-gui, ccmake (ncurses) would make it more obvious. Also future
>> documentation. :-)
>>
>> Ok, sooo much easier and understandable :) You should suggest this as the
> default method of configuring :D
> 
>>
>>> I think the configurescript should bypass the volk entirely when it
>> cannot
>>> build it?
>>>
>>
>> How can the configure know that volk cannot be built?
>>
>> Take a look in configure.log, it says a lot about things I do not have,
> might this not be an indicator?
> 
>> -Josh
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
> 
> Best Paul M. Bendixen
> 
> 
> 
> 
> ___
> 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] New build structure! (Warning #2)

[Dan CaJacob]

On 10/20/2011 02:01 PM, Josh Blum wrote:


On 10/20/2011 10:46 AM, Alexandru Csete wrote:

On Thu, Oct 20, 2011 at 6:51 AM, Josh Blum  wrote:


On 10/19/2011 08:42 PM, Dan CaJacob wrote:

On 10/19/2011 09:43 PM, Tom Rondeau wrote:

... we need people to start using it and testing as much as possible.

Build went smoothly with cmake on Ubuntu 11.10 x64  Unfortunately, it
built as 32 bit, but it works.  I usually build with Marcus Leech's
script which handles the architecture automatically.  I assume I could
have given it a proper flag to build as 64 bit?  Basically it installed
to /usr/local/lib/... instead of /usr/local/lib64/...


lib64 is a redhat thing, so that should be correct for ubuntu


Actually, it's also used in Ubuntu 11.10 now. I just built UHD and GNU
Radio yesterday. UHD installed in lib/ while GNU Radio (using
autotools) went to lib64/


Not sure why gnuradio autofoo is doing that. Its only supposed to
install lib64 when /etc/redhat-release (i think) file is found and 64
bit. So something must be confused.

-josh
I think he might be using ML's build-gnuradio script, which installs to 
lib64 if the directory exists, regardless of whether the operating 
system in RH.  That's why I was confused when it didn't install to lib64 
when I was testing cmake.


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

Re: [Discuss-gnuradio] New build structure! (Warning #2)

[Josh Blum]

> does this mean that i could perform the steps
> 
> /mkdir build
> cd build
> cmake -DCPACK_GENERATOR=DEB ../
> make package/
> 
> and make deb(s) of the current git release ? which is the switch to

Basically, yes that will generate a big deb file for the whole project.
There are a few considerations to do it right.

1) A list of all the dependencies for the package manager. This needs to
be defined per supported OS because the names are different across os
versions and os. I am thinking recent fedoras, ubuntus, and some debians.

2) Some prerm/postinst rules to run ldconfig to install grc icons, etc..
This is called pre/post install/uninstall for rpms

3) And if you want component based deps/rpms, you need to do something
different. I started this work and there have been a few posts about it.
The important thing is that the install rules in cmake all specify a
component so its easy to get a list of files per component (then do some
magic with it). Branch here:
http://gnuradio.org/cgit/jblum.git/log/?h=multi_deb

Basically there is still work to be done

> disable one of the components ?
> 

See the configure verbose or checkout cmake-gui or ccmake (ncurses). You
will see all the ENABLE_* variables for each component

-josh

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

Re: [Discuss-gnuradio] New build structure! (Warning #2)

[Marcus D. Leech]

On 20/10/2011 2:35 PM, Dan CaJacob wrote:
I think he might be using ML's build-gnuradio script, which installs 
to lib64 if the directory exists, regardless of whether the operating 
system in RH.  That's why I was confused when it didn't install to 
lib64 when I was testing cmake.


___

Actually the only thing that the build-gnuradio script does that could 
possibly affect where things get installed is that it sets
  PKG_CONFIG_PATH to /usr/local/lib/pkgconfig, and if 
/usr/local/lib64/pkgconfig exists, it sets it to that instead, before

  calling the bulk of the gnuradio builder chain.




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

Re: [Discuss-gnuradio] Fwd: volk build error

[Josh Blum]

On 10/19/2011 08:22 PM, Stevie wrote:
> Hi,
> 
> I'm experiencing problems with volk when building on an amd64 Debian
> "testing". It started when volk was first introduced to the git tree and is
> also my experience with the 3.4 release. When I build I get the following:
> 
> make[4]: Entering directory `/home/stevie/SourceCode/gnuradio/volk/lib'
> /bin/bash ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I..
>  -I../include -I../lib -I/usr/include  -I../include -I../gen/include
> -Dvolk_EXPORTS -fvisibility=hidden -DLV_MACHINE_SSE3_64
> -DLV_MACHINE_GENERIC  -DLV_MACHINE_SSE2_64  -DLV_MACHINE_SSE2_ONLY
>  -DLV_MACHINE_SSE4_1_64   -DLV_MACHINE_SSSE3_64-g -O2 -MT
> libvolk_la-volk.lo -MD -MP -MF .deps/libvolk_la-volk.Tpo -c -o
> libvolk_la-volk.lo `test -f '../gen/lib/volk.c' || echo
> './'`../gen/lib/volk.c
> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I../lib
> -I/usr/include -I../include -I../gen/include -Dvolk_EXPORTS
> -fvisibility=hidden -DLV_MACHINE_SSE3_64 -DLV_MACHINE_GENERIC
> -DLV_MACHINE_SSE2_64 -DLV_MACHINE_SSE2_ONLY -DLV_MACHINE_SSE4_1_64
> -DLV_MACHINE_SSSE3_64 -g -O2 -MT libvolk_la-volk.lo -MD -MP -MF
> .deps/libvolk_la-volk.Tpo -c ../gen/lib/volk.c  -fPIC -DPIC -o
> .libs/libvolk_la-volk.o
> In file included from ../gen/lib/volk.c:6:0:
> ../gen/lib/volk_machines.h:20:5: error: unknown type name
> 'p_16i_x5_add_quad_16i_x4_a'
> ../gen/lib/volk_machines.h:25:5: error: unknown type name
> 'p_16i_branch_4_state_8_a'
> ../gen/lib/volk_machines.h:30:5: error: unknown type name
> 'p_16ic_deinterleave_16i_x2_a'
> ../gen/lib/volk_machines.h:35:5: error: unknown type name
> 'p_16ic_s32f_deinterleave_32f_x2_a'
> ../gen/lib/volk_machines.h:40:5: error: unknown type name
> 'p_16ic_deinterleave_real_16i_a'
> ../gen/lib/volk_machines.h:45:5: error: unknown type name
> 'p_16ic_s32f_deinterleave_real_32f_a'
> ../gen/lib/volk_machines.h:50:5: error: unknown type name
> 'p_16ic_deinterleave_real_8i_a'
> ../gen/lib/volk_machines.h:55:5: error: unknown type name
> 'p_16ic_magnitude_16i_a'
> ../gen/lib/volk_machines.h:60:5: error: unknown type name
> 'p_16ic_s32f_magnitude_32f_a'
> ../gen/lib/volk_machines.h:65:5: error: unknown type name
> 'p_16i_s32f_convert_32f_a'
> ../gen/lib/volk_machines.h:75:5: error: unknown type name
> 'p_16i_convert_8i_a'
> ../gen/lib/volk_machines.h:85:5: error: unknown type name
> 'p_16i_max_star_16i_a'
> ../gen/lib/volk_machines.h:90:5: error: unknown type name
> 'p_16i_max_star_horizontal_16i_a'
> ../gen/lib/volk_machines.h:95:5: error: unknown type name
> 'p_16i_permute_and_scalar_add_a'
> ../gen/lib/volk_machines.h:100:5: error: unknown type name
> 'p_16i_x4_quad_max_star_16i_a'
> ../gen/lib/volk_machines.h:105:5: error: unknown type name
> 'p_16u_byteswap_a'
> ...
> 
> and so on for a huge list of unknown types and then lots of errors later on
> because these types haven't been defined.
> 

I recommend that you clean the generated files from the source tree. I
think that was the issue for someone else w/ a volk issue.
git clean -dfx

-josh

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

Re: [Discuss-gnuradio] Fwd: volk build error

[Marcus D. Leech]

On 20/10/2011 3:07 PM, Josh Blum wrote:


I recommend that you clean the generated files from the source tree. I
think that was the issue for someone else w/ a volk issue.
git clean -dfx

-josh

In which case, what it might mean is that generated "artifacts" have 
gotten checked-in to the git tree that shouldn't have been.


The naive approach of "git add *.c *.cpp *.h *.hpp" is likely not a good 
thing to do when the directory may contain both
  generated files and non-generated files of the same template.  I've 
done it myself.  It leads to badness.





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

Re: [Discuss-gnuradio] New build structure! (Warning #2)

[Arturo Rinaldi]

Il 20/10/2011 20:53, Josh Blum ha scritto:

does this mean that i could perform the steps

/mkdir build
 cd build
 cmake -DCPACK_GENERATOR=DEB ../
 make package/

and make deb(s) of the current git release ? which is the switch to

Basically, yes that will generate a big deb file for the whole project.
There are a few considerations to do it right.

1) A list of all the dependencies for the package manager. This needs to
be defined per supported OS because the names are different across os
versions and os. I am thinking recent fedoras, ubuntus, and some debians.

2) Some prerm/postinst rules to run ldconfig to install grc icons, etc..
This is called pre/post install/uninstall for rpms

3) And if you want component based deps/rpms, you need to do something
different. I started this work and there have been a few posts about it.
The important thing is that the install rules in cmake all specify a
component so its easy to get a list of files per component (then do some
magic with it). Branch here:
http://gnuradio.org/cgit/jblum.git/log/?h=multi_deb

Basically there is still work to be done


disable one of the components ?


See the configure verbose or checkout cmake-gui or ccmake (ncurses). You
will see all the ENABLE_* variables for each component

-josh

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

In fact I just experienced a dependency name incompatibility with 
/python-Cheetah/ instead of /python-cheetah/ (on Ubuntu). I can't 
install the whole package because of a silly capital C ! ! ! :D


I read about your multi_deb project, it's like as doing a cmake package 
for every single component, am i right ?


As a matter of fact every single module is built. I requested some time 
ago help about build errors for the /volk/ module (on Ubuntu 10.10) but 
with the latest git release it builds as well as the others.


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

Re: [Discuss-gnuradio] Warning! Warning!

[Mark Cetilia]

Great, thanks for the clarification, Marcus (and Tom)…
Looking forward to the new developments!

Cheers,
Mark

--
mark.cetilia.org | mem1.com | reduxproject.com

On Oct 20, 2011, at 12:01 PM, Marcus D. Leech wrote:

> 
> On 20/10/2011 11:58 AM, Mark Cetilia wrote:
>> What does this mean in terms of using older non-UHD-native daughterboards 
>> such as the DBSRX&  BasicRX?
>> To be honest, I haven't checked into the UHD driver, since the 
>> daughterboards I have been working fine without it…
>> 
>> Best,
>> Mark
>> 
>> 
> UHD supports ALL of the previous daughtercards, even ones that are no longer 
> in production and pre-date UHD.
> 
> 
> ___
> 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] New build structure! (Warning #2)

[Ben Hilburn]

Worked perfectly, first-attempt, with no special flags, on Arch =)

Cheers,
Ben


On Wed, Oct 19, 2011 at 6:43 PM, Tom Rondeau  wrote:

> Another big change is happening today! Josh Blum has make GNU Radio build
> using cmake, and we are hoping to switch over to it completely. The 'next'
> branch has just pulled in his changes, and we now have parallel build
> systems, cmake and autofoo. We are trying to make cmake the default build
> system, so we need people to start using it and testing as much as possible.
> For people who have issues using cmake, the autofoo stuff will still be
> there. The parallel build system will be in place official from 3.5. As of
> 3.6, we will have made a decision to move to cmake or stay with autotools;
> the other will be removed. It is expected that we will move to cmake, so
> this is a Warning to everyone that autotools is being deprecated as our
> build method.
>
> Details about using cmake can be found here:
> http://gnuradio.org/redmine/projects/gnuradio/wiki/CMakeWork
>
>  To summarizes:
>
> $ cd gnuradio
> $ git checkout next
> $ git pull
> $ mkdir build
> $ cd build
> $ cmake ../
> $ make
> $ make test
> $ sudo make install
>
> Again, if that fails but you really need to use the current next branch,
> the same autotools build process will work. Please let us know if you find
> any issues.
>
> Thanks!
> Tom
>
>
> ___
> 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

[Discuss-gnuradio] Developers call

[Tom Rondeau]

Starts in 15 minutes:

http://gnuradio.org/redmine/projects/gnuradio/wiki/Call20111020

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

Re: [Discuss-gnuradio] Developers call

[Marcus D. Leech]

On 20/10/2011 5:47 PM, Tom Rondeau wrote:

Starts in 15 minutes:

http://gnuradio.org/redmine/projects/gnuradio/wiki/Call20111020

Tom


I can't join the call, but I'll comment that if the application gets an 
EPIPE, it aint *never* coming back from that.  EPIPE indicates
   that the other side has closed its file descriptor, and has likely 
exited.  So, I don't know whether silently dropping samples, or
  doing the SINK-side version of "we're done" (like we have for SOURCE) 
is more appropriate.



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

Re: [Discuss-gnuradio] New build structure! (Warning #2)

[Marcus D. Leech]

Worked perfectly, first-attempt, with no special flags, on Arch =)

Cheers,
Ben

I just built in on Fedora 14, on an AMD64 multi-core system.  Flawless.


--
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] Warning! Warning!

[Achilleas Anastasopoulos]

> All USRP daughterboards are supported in UHD. You should have no problems
> with DBSRX and BasicRX.
>
> Tom

I think this is not entirely true:

I have a TVRX that is  not recognised by the uhd driver...

Achilleas





Message: 6
Date: Thu, 20 Oct 2011 09:46:22 -0700
From: Tom Rondeau 
To: Mark Cetilia 
Cc: GNURadio Discussion List 
Subject: Re: [Discuss-gnuradio] Warning! Warning!
Message-ID:
   
Content-Type: text/plain; charset="windows-1252"

On Thu, Oct 20, 2011 at 8:58 AM, Mark Cetilia  wrote:

> What does this mean in terms of using older non-UHD-native daughterboards
> such as the DBSRX & BasicRX?
> To be honest, I haven't checked into the UHD driver, since the
> daughterboards I have been working fine without it?
>
> Best,
> Mark



All USRP daughterboards are supported in UHD. You should have no problems
with DBSRX and BasicRX.

Tom

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

[Discuss-gnuradio] building new "next" branch successful in F15-64

[Achilleas Anastasopoulos]

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

[Discuss-gnuradio] gr-trellis broken on next branch

[Achilleas Anastasopoulos]

After installing the next branch i realized that gr-trellis is not
working properly!

This is due to some work (by Ben Raynwar) that makes gr-trellis
dependent on gr-digital (???)
In particular the constants related to trellis_metric_type.h cannot be
accessed in python/grc
as part of the trellis module, but as part of the digital module
(this problem appears for instance if you run some of the pccc/sccc
examples in gnuradio-examples/grc/trellis).

This can be an easy fix (import digital in all the grc blocks
requiring metric types, and make appropriate changes).

However I wonder what is the point of making a self-contained
module like gr-trellis dependent on another module (gr-digital)
If the only reason is to to use the "constellation" object in the
"metrics" blocks then these blocks should
reside in the gr-digital module instead of the gr-trellis, so that the
latter can still be self-contained.

Ben, can you please explain what is your rational in doing these changes.

thanks,
Achilleas

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

Re: [Discuss-gnuradio] New build structure! (Warning #2)

[Daniel Dekst]

Tried on USRP E100 kernel module 3.0.0
Error when make.

[ 13%] Building C object 
gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/filter/dotprod_fff_armv7_a.c.o
/program/gnuradio/gnuradio-core/src/lib/filter/dotprod_fff_armv7_a.c: In 
function 'dotprod_fff_armv7_a':
/program/gnuradio/gnuradio-core/src/lib/filter/dotprod_fff_armv7_a.c:67:5: 
error: impossible register constraint in 'asm'
make[2]: *** 
[gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/filter/dotprod_fff_armv7_a.c.o]
 Error 1
make[1]: *** [gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/all] Error 2
make: *** [all] Error 2




2011/10/20 


>Message: 10
>Date: Wed, 19 Oct 2011 18:43:32 -0700
>From: Tom Rondeau 
>To: GNURadio Discussion List 
>Subject: [Discuss-gnuradio] New build structure! (Warning #2)
>Message-ID:
>       
>Content-Type: text/plain; charset="iso-8859-1"
>
>Another big change is happening today! Josh Blum has make GNU Radio build
>using cmake, and we are hoping to switch over to it completely. The 'next'
>branch has just pulled in his changes, and we now have parallel build
>systems, cmake and autofoo. We are trying to make cmake the default build
>system, so we need people to start using it and testing as much as possible.
>For people who have issues using cmake, the autofoo stuff will still be
>there. The parallel build system will be in place official from 3.5. As of
>3.6, we will have made a decision to move to cmake or stay with autotools;
>the other will be removed. It is expected that we will move to cmake, so
>this is a Warning to everyone that autotools is being deprecated as our
>build method.
>
>Details about using cmake can be found here:
>http://gnuradio.org/redmine/projects/gnuradio/wiki/CMakeWork
>
>To summarizes:
>
>$ cd gnuradio
>$ git checkout next
>$ git pull
>$ mkdir build
>$ cd build
>$ cmake ../
>$ make
>$ make test
>$ sudo make install
>
>Again, if that fails but you really need to use the current next branch, the
>same autotools build process will work. Please let us know if you find any
>issues.
>
>Thanks!
>Tom
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] New build structure! (Warning #2)

[Josh Blum]

On 10/20/2011 10:22 PM, Daniel Dekst wrote:
> 
> Tried on USRP E100 kernel module 3.0.0
> Error when make.
> 
> [ 13%] Building C object 
> gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/filter/dotprod_fff_armv7_a.c.o
> /program/gnuradio/gnuradio-core/src/lib/filter/dotprod_fff_armv7_a.c: In 
> function 'dotprod_fff_armv7_a':
> /program/gnuradio/gnuradio-core/src/lib/filter/dotprod_fff_armv7_a.c:67:5: 
> error: impossible register constraint in 'asm'
> make[2]: *** 
> [gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/filter/dotprod_fff_armv7_a.c.o]
>  Error 1
> make[1]: *** [gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/all] Error 2
> make: *** [all] Error 2
> 
> 

You may want to experiment with compiler flags. Try this:

cmake -DCMAKE_CXX_FLAGS:STRING="-mcpu=cortex-a8 -mfpu=neon
-mfloat-abi=softfp -g" -DCMAKE_C_FLAGS:STRING="-mcpu=cortex-a8
-mfpu=neon -mfloat-abi=softfp -g" 

-josh

> 
> 
> 2011/10/20 
> 
> 
>> Message: 10
>> Date: Wed, 19 Oct 2011 18:43:32 -0700
>> From: Tom Rondeau 
>> To: GNURadio Discussion List 
>> Subject: [Discuss-gnuradio] New build structure! (Warning #2)
>> Message-ID:
>>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> Another big change is happening today! Josh Blum has make GNU Radio build
>> using cmake, and we are hoping to switch over to it completely. The 'next'
>> branch has just pulled in his changes, and we now have parallel build
>> systems, cmake and autofoo. We are trying to make cmake the default build
>> system, so we need people to start using it and testing as much as possible.
>> For people who have issues using cmake, the autofoo stuff will still be
>> there. The parallel build system will be in place official from 3.5. As of
>> 3.6, we will have made a decision to move to cmake or stay with autotools;
>> the other will be removed. It is expected that we will move to cmake, so
>> this is a Warning to everyone that autotools is being deprecated as our
>> build method.
>>
>> Details about using cmake can be found here:
>> http://gnuradio.org/redmine/projects/gnuradio/wiki/CMakeWork
>>
>> To summarizes:
>>
>> $ cd gnuradio
>> $ git checkout next
>> $ git pull
>> $ mkdir build
>> $ cd build
>> $ cmake ../
>> $ make
>> $ make test
>> $ sudo make install
>>
>> Again, if that fails but you really need to use the current next branch, the
>> same autotools build process will work. Please let us know if you find any
>> issues.
>>
>> Thanks!
>> Tom
>>
>>
>>
> 
> 
> 
> ___
> 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