Tuesday, January 31, 2012

[Discuss-gnuradio] WInnForum SDR Design Challenge -- entries due 17 February, projects in progress welcome

The Wireless Innovation Forum invites entries for the Software-Defined
Radio Design Challenge, a student design contest. This contest is an
activity of the Forum's Educational Special Interest Group. The
competition will take place on May 31, 2012 at the Wireless@Virginia
Tech Symposium on Wireless Communications, Blacksburg, VA, USA.
Projects entered in the contest will be judged by wireless
communications industry professionals.

Proposals are due February 17, 2012. For more information, please see
http://groups.winnforum.org/p/wi/et/wid=24


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

Re: [Discuss-gnuradio] software for antenna designers

Well the core ( nec2 ) is open source and so runs on linux, but your GUI ( EZNEC+ ) is not. You could try Wine, I believe 4nec2 works well with it, 4nec2 is a much more advanced program too. 

On Tue, Jan 31, 2012 at 7:48 PM, Patrik Tast <patrik@poes-weather.com> wrote:
Hi All,
 
Do you know of an/any antenna software you would use for linux that does like EZNEC+ v5.0 (licenced) http://www.eznec.com/
 
Patrik

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


Re: [Discuss-gnuradio] Unable to receive using USRP N210, XCVR2450 daughterboards running benchmark programs

On 31/01/12 09:53 PM, shantharam balasubramanian wrote:
> When the transmitter was producing the dots, are you 100% sure that
> the packets were gettting transmitted in the first place?
>
> cause i used spectrum analyser and i ran uhd_fft.py, and saw that no
> signals were peaking up on that particular frequency. Even Tom had the
> same doubt when he visited my lab today, and told me to check if the
> transmitter was transmitting the packets. I dont think it does.
>
So, why not use uhd_siggen.py or similar to produce a simple
single-tone, at a desired frequency, and look for
*that*. Debug using the simplest tools at your disposal, not the most
complicated ones.


--
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] Unable to receive using USRP N210, XCVR2450 daughterboards running benchmark programs

When the transmitter was producing the dots, are you 100% sure that the packets were gettting transmitted in the first place?

cause i used spectrum analyser and i ran uhd_fft.py, and saw that no signals were peaking up on that particular frequency. Even Tom had the same doubt when he visited my lab today, and told me to check if the transmitter was transmitting the packets. I dont think it does.


Re: [Discuss-gnuradio] Unable to receive using USRP N210, XCVR2450 daughterboards running benchmark programs

Hi Dhrubojyoti,

I also observed the same experimental results, i.e., (1) fail to receive packets using benchmark programs; (2) 1MHz shift with XCVR2450 daughterboard. Sometimes, the wider bandwidth (or higher sample rate) and shifted central frequency help.

Regards,
Lizhao


2012/1/9 Dhrubojyoti Roy <dhrubojyoti.roy@gmail.com>
Hi All,

I´m new to GNUradio and have run into the basic problem of the receiver USRP device not being able to decode the senderÅ› transmission. For our experiments, we used GNUradio (MAJOR_VERSION=3, API_COMPAT=5, MINOR_VERSION=1) and USRP N210 with XCVR2450 daughterboards, and the benchmark_tx/rx programs for both narrowband and ofdm. We used the following transmitter arguments and got the result below:

./benchmark_tx.py -f 2.4G -r 2M -M 10 -v

linux; GNU C++ version 4.5.2; Boost_104200; UHD_003.004.000-f2388c0

>>> gr_fir_ccf: using SSE

Modulator:
bits per symbol:     4
RRC roll-off factor: 0.35
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes

No gain specified.
Setting gain to 17.500000 (from [0.000000, 35.000000])

UHD Transmitter:
Args:    
Freq:        2.4GHz
Gain:        17.500000 dB
Sample Rate: 1Msps
Antenna:     None
Subdev Sec:  None

Modulator:
bits per symbol:     4
RRC roll-off factor: 0.35
Tx amplitude     0.25
modulation:      psk_mod
bitrate:         2Mb/s
samples/symbol:  2.0000
Differential:    True
...........................................................(sending the data)

We invoked the receiver as follows:

./benchmark_rx.py -f 2.4G -r 2M -v

linux; GNU C++ version 4.5.2; Boost_104200; UHD_003.004.000-f2388c0

>>> gr_fir_ccf: using SSE

Demodulator:
bits per symbol:     4
RRC roll-off factor: 0.35
FLL bandwidth:       6.28e-02
Timing bandwidth:    6.28e-02
Phase bandwidth:     6.28e-02
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes

No gain specified.
Setting gain to 49.500000 (from [0.000000, 99.000000])

UHD Receiver:
UHD Args:   
Freq:        2.4GHz
Gain:        49.500000 dB
Sample Rate: 1Msps
Antenna:     None
Spec:        None

Demodulator:
bits per symbol:     4
RRC roll-off factor: 0.35
FLL bandwidth:       6.28e-02
Timing bandwidth:    6.28e-02
Phase bandwidth:     6.28e-02

Receive Path:
modulation:      psk_demod
bitrate:         2Mb/s
samples/symbol:  2.0000
Differential:    True

At this point, even with the transmitter running, the receiver program pauses for about a minute before bursting into a string of ´O´s. We found that our transmission was being detected by the receiving USRP, using the uhd_fft.py program. However, an interesting observation was that our signal was detected at center frequency 2.401GHz (screenshot attached). We doubt if this is due to oscillator differences, since switching the transmitter and receiver devices also resulted in detection at the same 2.401GHz center frequency.

We tried variations to the above programs by making the benchmark_rx.py listen in th 2.401GHz frequency, other modulation schemes such as qam, different transmission gains and also the OFDM benchmarks with similar variations, but there was no output on the receiver. Could it be possible that the receiver can detect but cannot decode the signal? Your valuable advice in this regard would be sincerely appreciated.

Thanks and Regards,
Dhrubojyoti.
 
--
Dhrubojyoti Roy
1655, North 4th Street, Apt-D
Columbus, OH-43201
Contact no.: +1-740-417-5890


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


Re: [Discuss-gnuradio] reg problem in running gnuradio 3.5 benchmark programs

Hi

I just want to list down the commands I used to run the benchmark programs.

./benchmark_tx.py -f 2.4G -r 1M --args "addr=192.168.10.2".  In addition I also gave the option [-A J1] to select the antenna to transmit. But I couldnt detect any transmitted signal from that node.

I also ran uhd_fft in receiver to graphically see if there is any signal getting received. but still couldnt see any.

uhd_fft.py -f 2.4G -s 1M --args "addr=192.168.10.2"


It will be of great help if someone can help me out with this.


Thanks

Re: [Discuss-gnuradio] Running tunnel.py/benchmark_tx.py (OFDM) with XCVR2450?

On 01/31/2012 08:21 PM, Andrew Davis wrote:
That's kinda odd now that I think about it, I had a similar problem and on an oscilloscope it looked like DAC clipping, but I could have been non-linearity in the final amp, what kind of problems do XCVR2450 have at high outputs? 

All amplifiers will have non-linear operating regions up near their maximum output power.  Clipping in the DAC shouldn't be approached until
  the signal magnitudes approach +/- 1.0.

I don't believe the XCVR2450 is special in this regard.

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

Re: [Discuss-gnuradio] Running tunnel.py/benchmark_tx.py (OFDM) with XCVR2450?

That's kinda odd now that I think about it, I had a similar problem and on an oscilloscope it looked like DAC clipping, but I could have been non-linearity in the final amp, what kind of problems do XCVR2450 have at high outputs? 

On Tue, Jan 31, 2012 at 9:00 AM, Marcus D. Leech <mleech@ripnet.com> wrote:
On 31/01/12 08:37 AM, Andrew Davis wrote:
>One thing that I noticed was that the --tx-amp=0.8. That's very high for OFDM with it's large PAPR.

I'm thinking that too, there really should be some kind of warning when you drive the DAC to saturation.
It's not the DAC that's typically the problem, it's the final RF amplifier on the daughter-card, and
  that's not precisely predictable from the software side.



--  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


[Discuss-gnuradio] reg problem in running gnuradio 3.5 benchmark programs

Hi

I installed gnuradio 3.5 images in my college lab, and I installed the appropriate SD card image for it.

I then tried to run the benchmark programs, by running the benchmark_tx  and rx in two different nodes that have USRP2, with daughter boards, XCVR 2450 in them.

But I saw that the benchmark_rx didnt receive any packets from the node which was running the benchmark_tx in it. There was a problem of overrun in the node running benchmark_rx, but still it didnt receive any packets from the node running the transmitter program.

Following the advice of tom, we then ran the benchmark_tx and saw that there were no signal being shown in spectrum analyzer, kept near to the transmitter node. But still the program was showing the dots, indicating that it was sending the packets.

Can anyone tell me why this problem occurs and what should I do to resolve it?


Thanks



--
Regards

Shantharam Balasubramanian
MS in Electrical and Computer Engineering
Rutgers University
Ph:732-543-6863
Email:shantharampsg@gmail.com

Re: [Discuss-gnuradio] Down for everyone? A Yup, seems to be

On Tue, Jan 31, 2012 at 16:33, Philip Balister <philip@balister.org> wrote:

> Looks a bit sluggish here also .....

The server CPU and memory load on gnuradio.org has been steadily
increasing since Tom and I moved it to Amazon Web Services hosting
last June. We're beginning to max out the instance type we chose back
then, and will have to migrate to a larger VM. We had hoped to wait
until the next LTS version of Ubuntu server, but obviously it will
have to happen much sooner. I suppose that's a good problem for the
project to be having :-)

Johnathan

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

[Discuss-gnuradio] software for antenna designers

Hi All,
 
Do you know of an/any antenna software you would use for linux that does like EZNEC+ v5.0 (licenced) http://www.eznec.com/
 
Patrik

Re: [Discuss-gnuradio] Down for everyone? A Yup, seems to be

Looks a bit sluggish here also .....

On 01/31/2012 06:49 PM, Marcus D. Leech wrote:
> www.gnuradio.org appears to be down (and no, it's not just me :-) )
>
>

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

[Discuss-gnuradio] Down for everyone? A Yup, seems to be

www.gnuradio.org appears to be down (and no, it's not just me :-) )


--
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] Running tunnel.py/benchmark tx.py (OFDM) with XCVR2450?

On 01/31/2012 02:48 PM, Florian Schlembach wrote:
> Ok, that definitely makes sense if there is no error correction is
> implemented.
>
> We are now trying to establish an TCP/IP connection between both USRP2s
> with the tunnel.py script.
> Unfortunately, it says "Destination Host unreachable" when pinging the
> other USRP. We should have set up the tunnel correct as some packets are
> received and transmitted after having configured the IP address. The
> pinged USRPs is indicating the received icmp packet but there is still
> no confirmed ping-request though.
>

Short answer; dont do that. Yes, this particular USRP is a network
device, but that is completely unrelated to the purpose of tunnel.py.
You probably have to play with routing tables to make this work...

> Do you have an idea why the pinging is not working after having
> established the tunnel.py connection?
>

Try pinging a service that is running on the remote virtual interface on
host PC0 from the local virtual interface on host PC1.

_josh

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

Re: [Discuss-gnuradio] Running tunnel.py/benchmark tx.py (OFDM) with XCVR2450?

Ok, that definitely makes sense if there is no error correction is
implemented.

We are now trying to establish an TCP/IP connection between both USRP2s
with the tunnel.py script.
Unfortunately, it says "Destination Host unreachable" when pinging the
other USRP. We should have set up the tunnel correct as some packets
are received and transmitted after having configured the IP address.
The pinged USRPs is indicating the received icmp packet but there is
still no confirmed ping-request though.

Do you have an idea why the pinging is not working after having
established the tunnel.py connection?


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

[Discuss-gnuradio] Effect of having multiple throttle in a chain of flowgraph

Hi,

I would like to ask what happen if there are many block of throttle connected between a source and a sink in pure simulation? I notice the GUI Interface (wxgui) is getting slow when 5 throttle block is connected between a signal source and signal probe sink.

| Signal Block | ---> | Throttle | ---> | Throttle | ---> | Throttle | ---> | WX GUI Scope Sink |

--
Regards,
Muhammad b Rosli


Re: [Discuss-gnuradio] Error while running std examples max_power.py, bert : boost::math::round(d): Value -nan

>>
> Just the frequency option (-f 2440M).
>
> -Shalabh

I am suspecting a possible issue with an initialized variable. Do you
mind trying this little patch: http://www.pastebucket.com/1402

-Josh

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

Re: [Discuss-gnuradio] Question !

On 31/01/12 04:38 PM, Javier Suarez wrote:
Good morning,
My name is Javier Mauricio Suarez, I am a student of electronics engineering at Santander Industrial University in Colombia. I am working with the USRP1 and GNU Radio for my graduate project. Some days ago I had a problem that I haven't been able to solve. I try to  verify that GNU Radio works with the USRP1, for doing that I write the following code lines in the terminal:
>From the gnu radio directory:
 cd gnuradio-examples/python/usrp ./usrp_benchmark_usb.py   
cd usrp/host/apps ./test_usrp_standard_tx ./test_usrp_standard_rx   


this provided by the web page of gnu radio:   http://gnuradio.org/redmine/projects/gnuradio/wiki/UbuntuInstall#Configuring-USRP-support

In both cases, when I run these code lines I have the following warning and error:

Warning: Treating daughterboard with invalid EEPROM contents as if it were a "Basic Tx."
Warning: This is almost certainly wrong...  Use appropriate burn-*-eeprom utility.

 I am using the next hardware:
USRP1
motherboard:    Rev:4.5    serial number:6296

daughter board:    RFX 2200    STM-5    94 V  Rev 30   2400-2500 MHz transceiver

I am using gnuradio 3.4-1
and ubuntu version 10.04



I would be very greatful if you can help me with that.

Regards
Javier Mauricio Suarez
   
The RFX2200 came out *after* the transition to UHD, and the examples you are using are not UHD aware.
 Basically the "classic" drivers don't know anything about an RFX2200 card.


My suggestion would be to use:

http://www.sbrac.org/files/build-gnuradio

To download/build/install the latest UHD plus Gnu Radio and proceed from there.

The "classic" drivers have been unmaintained and "obsolete" for two years now


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

Re: [Discuss-gnuradio] Error while running std examples max_power.py, bert : boost::math::round(d): Value -nan

On Tue, Jan 31, 2012 at 7:54 AM, Marcus D. Leech <mleech@ripnet.com> wrote:
On 31/01/12 01:24 AM, Shalabh Jain wrote:



Just the frequency option (-f 2440M).

-Shalabh
My suspicion is that you're not using the version of Gnu Radio you think you're using, and there's an
 ABI difference between UHD and gr-uhd.

After you re-built UHD and Gnu Radio, did you "sudo ldconfig"?

Yes I did do that. I just rechecked the system for any previous installation files, but there isn't anything. My gnuradio and uhd installs are in specific directory rather than the default locations, so I can claim this with certainty.  What I can try is to do a fresh install of latest gnuradio and uhd branch on my personal laptop and see if this error persists. I'll report the results of that once I return home.

I can add another random finding to this since I tried rebooting the machine. If my kernel buffers are set to the default size, I get the std UHD warning to resize. However, the gui comes up for uhd_fft.py. But if I resize the buffers as suggested, I get the previously mentioned errors. Though the bert example errors out in both the cases.

-Shalabh



[Discuss-gnuradio] Question !

Good morning,
My name is Javier Mauricio Suarez, I am a student of electronics engineering at Santander Industrial University in Colombia. I am working with the USRP1 and GNU Radio for my graduate project. Some days ago I had a problem that I haven't been able to solve. I try to  verify that GNU Radio works with the USRP1, for doing that I write the following code lines in the terminal:
From the gnu radio directory:

cd gnuradio-examples/python/usrp
./usrp_benchmark_usb.py
cd usrp/host/apps
./test_usrp_standard_tx
./test_usrp_standard_rx


this provided by the web page of gnu radio:   http://gnuradio.org/redmine/projects/gnuradio/wiki/UbuntuInstall#Configuring-USRP-support

In both cases, when I run these code lines I have the following warning and error:

Warning: Treating daughterboard with invalid EEPROM contents as if it were a "Basic Tx."
Warning: This is almost certainly wrong...  Use appropriate burn-*-eeprom utility.

 I am using the next hardware:
USRP1
motherboard:    Rev:4.5    serial number:6296

daughter board:    RFX 2200    STM-5    94 V  Rev 30   2400-2500 MHz transceiver

I am using gnuradio 3.4-1
and ubuntu version 10.04



I would be very greatful if you can help me with that.

Regards
Javier Mauricio Suarez

Re: [Discuss-gnuradio] Running tunnel.py/benchmark_tx.py (OFDM) with XCVR2450?

On 31/01/12 08:37 AM, Andrew Davis wrote:
>One thing that I noticed was that the --tx-amp=0.8. That's very high for OFDM with it's large PAPR.

I'm thinking that too, there really should be some kind of warning when you drive the DAC to saturation.
It's not the DAC that's typically the problem, it's the final RF amplifier on the daughter-card, and
  that's not precisely predictable from the software side.


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

Re: [Discuss-gnuradio] Running tunnel.py/benchmark_tx.py (OFDM) with XCVR2450?

>One thing that I noticed was that the --tx-amp=0.8. That's very high for OFDM with it's large PAPR.

I'm thinking that too, there really should be some kind of warning when you drive the DAC to saturation.

If you need more range use an external amp.

On Tue, Jan 31, 2012 at 8:28 AM, Tom Rondeau <tom@trondeau.com> wrote:
On Mon, Jan 30, 2012 at 11:12 AM, Martin Braun <martin.braun@kit.edu> wrote:
On Mon, Jan 30, 2012 at 04:11:05PM +0100, Florian Schlembach wrote:
> We have now extended our tests to the tests with two USRP2s with
> daughterboards: Neither the benchmark_tx.py example nor the tunnel.py is
> receiving any packets. We checked the spectrum and tuned the gains as well.
> (OFDM)
>
> Now, we played with the benchmark files and tunnel.py located in the narrowband
> folder and therefore changed the modulation scheme from BPSK to GMSK and
> ultimately receiving all the packets!! That's strange.
>
> Does anybody knows what code be the problem that we can't establish any
> connection using higher order modulation schemes? Could it possibly be our
> slightly outdated UHD version?
>
> We are totally clueless, so we appreciate any idea/help!

This won't really help, but I remember we had exactly the same troubles here.
This was before UHD was even released, so I doubt that's the reason.
Unfortunately, I can't remember how (or: if) we fixed it :( but I'll
keep you updated if my memory comes up with something.

But fiddling with gain values is often useful; even if you've already
done that I recommend trying again, by reducing tx-amplitude and the
actual gain values, shifting the terminals around (perhaps they're too
close?).

MB


The benchmark OFDM scripts were made as simple examples of OFDM and were not made very robust. I can get them working within an office space fairly easily, but I seem to be the only one. When I moved everything over the using the UHD interface, I tested everything OTA successfully, so they do still work.

One thing that I noticed was that the --tx-amp=0.8. That's very high for OFDM with it's large PAPR. Try backing off on that (to around 0.2 - 0.3) and try again. You won't get much range from this signal, though.

Tom
 

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


Re: [Discuss-gnuradio] Running tunnel.py/benchmark_tx.py (OFDM) with XCVR2450?

On 31/01/12 08:28 AM, Florian Schlembach wrote:
>> But fiddling with gain values is often useful; even if you've already
>> done that I recommend trying again, by reducing tx-amplitude and the
>> actual gain values, shifting the terminals around (perhaps they're too
>> close?).
>>
> We have now found out that we need a sampling rate of at least 2Msps
> which means we have to set the bandwidth to at least 2MHz (I read sth
> about that the USRPs have problems with higher decimation rates):
>
> ./benchmark_tx.py -f 2.400G -A TX/RX --tx-amplitude=0.2 -v -W 2M
> ./benchmark_rx.py -f 2.400G -A TX/RX --rx-gain=35 -v -W 2M
>
>
> The OFDM (bpsk) example is now working and all packets seems to be
> transmitted. Unfortunately, not all of the packets could be
> demodulated correctly as they are marked as "ok: False" - lets say a
> quarter of them. This would yield a really bad performance in terms of
> a reliable transmission. We also played around with the distance and
> the alignment of the omni antennas but ultimately, we could not get
> rid of the false packets.
>
> Have you encountered a similar bad performance? Have you also
> encountered such a strange behavior regarding the lower sampling rate?
> What else could we try?
>
> ______________________________________________
>
Frequency offset is the usual cause of such problems.

The master oscillators on a USRP vary between about 10PPM and 20PPM,
which at higher frequencies
means on offset of several kHz. A narrow-band signal suffers much
more from frequency offset issues
that a wideband one--the frequency error constitutes a larger fraction
of the overall signal.

Frequency offset errors are normal in any radio communications
system--since master oscillator frequencies
are *never* perfect. Real-world systems typically have an FLL or AFT
somewhere in the receive
chain to compensate.

This is why the last IF filter on a narrowband FM receiver is usually
wider than would be suggested by
the modulation bandwidth, and why there's usually some kind of AFT
feedback.


--
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] Updating the BBN_80211

On Fri, Jan 27, 2012 at 4:20 PM, NeoEcko <naceuramine@gmail.com> wrote:

Hi all,

I am new at the GNU Radio and UHD Fields.
I have recently begin to make some modifications at the bbn_80211 code
(which is compatible with the GNU Radio's 3.1.1 release) to make it run
with uhd and USRP N2X0.

But when modifying the "bbn80211.py" import section

"from gnuradio import usrp (or usrp2)" ==>  "from gnuradio import uhd"

I got this error "ImportError: cannot import name uhd "
and even when running some of the bbn's examples (bbn_80211_pkt;
bbn_80211_tap; bbn_80211_test) I got: "ImportError: cannot import name
bbn"

  - Is it a problem of linking some modules by setting environement
variables ?
Or - Am I supposed to bring modification to the 'Makefile' of the
bbn80211 and compile it again after all modifications are done.

Sorry if my questions are so general but if you see that I need to know
more about autotools don't hesitate to let me know.

Best regard,
***********************************
My GNU Radio version is the 3.4 and I am using USRP N210.

Yes, those BBN 802.11 scripts are fairly old, so it's going to take some work to update them to the latest software. But this sounds like an installation error.

You said you are having problems with the "import uhd", have you had success with other GNU Radio apps? Like can you run "uhd_fft.py" or "uhd_siggen.py". If you can't get those scripts to run, you probably haven't installed GNU Radio fully.

Good luck! I hope you manage to get the 802.11 code working.

Tom

Re: [Discuss-gnuradio] Running tunnel.py/benchmark_tx.py (OFDM) with XCVR2450?

On Tue, Jan 31, 2012 at 8:28 AM, Florian Schlembach <florian.schlembach@tu-ilmenau.de> wrote:
> But fiddling with gain values is often useful; even if you've already
> done that I recommend trying again, by reducing tx-amplitude and the
> actual gain values, shifting the terminals around (perhaps they're too
> close?).

We have now found out that we need a sampling rate of at least 2Msps
which means we have to set the bandwidth to at least 2MHz (I read sth
about that the USRPs have problems with higher decimation rates):

./benchmark_tx.py -f 2.400G -A TX/RX --tx-amplitude=0.2 -v -W 2M
./benchmark_rx.py -f 2.400G -A TX/RX --rx-gain=35 -v -W 2M


 The OFDM (bpsk) example is now working and all packets seems to be
transmitted. Unfortunately, not all of the packets could be
demodulated correctly as they are marked as "ok: False" - lets say a
quarter of them. This would yield a really bad performance in terms of
a reliable transmission. We also played around with the distance and
the alignment of the omni antennas but ultimately, we could not get
rid of the false packets.

Have you encountered a similar bad performance? Have you also
encountered such a strange behavior regarding the lower sampling rate?
What else could we try?

There is not channel coding on the packets. A packet of 1500 bytes is is 12000 bits. If a single bit is incorrect, the CRC check will fail and the packet is marked as bad.

You'll have to take the OFDM basic examples and extend them with error correcting codes to get anything like reliable performance from it.

Tom

Re: [Discuss-gnuradio] Running tunnel.py/benchmark_tx.py (OFDM) with XCVR2450?

On Mon, Jan 30, 2012 at 11:12 AM, Martin Braun <martin.braun@kit.edu> wrote:
On Mon, Jan 30, 2012 at 04:11:05PM +0100, Florian Schlembach wrote:
> We have now extended our tests to the tests with two USRP2s with
> daughterboards: Neither the benchmark_tx.py example nor the tunnel.py is
> receiving any packets. We checked the spectrum and tuned the gains as well.
> (OFDM)
>
> Now, we played with the benchmark files and tunnel.py located in the narrowband
> folder and therefore changed the modulation scheme from BPSK to GMSK and
> ultimately receiving all the packets!! That's strange.
>
> Does anybody knows what code be the problem that we can't establish any
> connection using higher order modulation schemes? Could it possibly be our
> slightly outdated UHD version?
>
> We are totally clueless, so we appreciate any idea/help!

This won't really help, but I remember we had exactly the same troubles here.
This was before UHD was even released, so I doubt that's the reason.
Unfortunately, I can't remember how (or: if) we fixed it :( but I'll
keep you updated if my memory comes up with something.

But fiddling with gain values is often useful; even if you've already
done that I recommend trying again, by reducing tx-amplitude and the
actual gain values, shifting the terminals around (perhaps they're too
close?).

MB


The benchmark OFDM scripts were made as simple examples of OFDM and were not made very robust. I can get them working within an office space fairly easily, but I seem to be the only one. When I moved everything over the using the UHD interface, I tested everything OTA successfully, so they do still work.

One thing that I noticed was that the --tx-amp=0.8. That's very high for OFDM with it's large PAPR. Try backing off on that (to around 0.2 - 0.3) and try again. You won't get much range from this signal, though.

Tom
 

Re: [Discuss-gnuradio] Running tunnel.py/benchmark_tx.py (OFDM) with XCVR2450?

> But fiddling with gain values is often useful; even if you've already
> done that I recommend trying again, by reducing tx-amplitude and the
> actual gain values, shifting the terminals around (perhaps they're too
> close?).

We have now found out that we need a sampling rate of at least 2Msps
which means we have to set the bandwidth to at least 2MHz (I read sth
about that the USRPs have problems with higher decimation rates):

./benchmark_tx.py -f 2.400G -A TX/RX --tx-amplitude=0.2 -v -W 2M
./benchmark_rx.py -f 2.400G -A TX/RX --rx-gain=35 -v -W 2M


The OFDM (bpsk) example is now working and all packets seems to be
transmitted. Unfortunately, not all of the packets could be
demodulated correctly as they are marked as "ok: False" - lets say a
quarter of them. This would yield a really bad performance in terms of
a reliable transmission. We also played around with the distance and
the alignment of the omni antennas but ultimately, we could not get
rid of the false packets.

Have you encountered a similar bad performance? Have you also
encountered such a strange behavior regarding the lower sampling rate?
What else could we try?

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

Re: [Discuss-gnuradio] Error while running std examples max_power.py, bert : boost::math::round(d): Value -nan

On 31/01/12 01:24 AM, Shalabh Jain wrote:



Just the frequency option (-f 2440M).

-Shalabh
My suspicion is that you're not using the version of Gnu Radio you think you're using, and there's an
 ABI difference between UHD and gr-uhd.

After you re-built UHD and Gnu Radio, did you "sudo ldconfig"?




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

Re: [Discuss-gnuradio] trellis encoder and OFDM modulator

Hi

I was also looking around the OFDM Modulation recently. Found this nice
project here: http://people.csail.mit.edu/szym/rawofdm/README.html
where ofdm mod and channel est are done separately. I didn't had the
time to follow ths more...perhaps it helps.

best, friederike

On 01/20/2012 02:38 PM, vanITA1082 wrote:
>
> Did you solve it?
>
> I am trying to add FEC in the OFDM chain but I didn't figure out how to do
> this, yet.
>
> Any advice or do you know if someone did it and the code is public?
>
> Thanks
>
> Veljko Pejovic wrote:
>>
>> Hi,
>>
>> I tried to use trellis_encoder from trellis package to perform
>> convolution coding before sending the message to the OFDM modulator.
>> However, ofdm_mod has zero input signature, and relies on send_pkt()
>> which calls ofdm_packet_utils.make_packet() and then puts the message
>> in the queue at gr.ofdm_mapper_bcv. Since the chain basically starts
>> with ofdm_mod I don't see the way to connect the trellis_encoder
>> before the signal is already modulated. In ftw80211 project they
>> modify ofdm_packet_utils and write their own convolution coding
>> method, I could do the same, but then I would miss all the benefits of
>> this nice trellis package.
>>
>> Interestingly, the other modulation blocks such as dbpsk or d8psk have
>> different input signatures, and I would put the trellis_encoder
>> between the gr.message_source and modulator in pkt.py. Is there a way
>> to seamlessly introduce trellis_encoder in the flow graph with an OFDM
>> modulator? Am I missing something here?
>>
>>
>> Thanks,
>>
>>
>> Veljko
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>

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

Monday, January 30, 2012

Re: [Discuss-gnuradio] Error while running std examples max_power.py, bert : boost::math::round(d): Value -nan

On Mon, Jan 30, 2012 at 9:54 PM, Marcus D. Leech <mleech@ripnet.com> wrote:
On 30/01/12 09:36 PM, Shalabh Jain wrote:
>
> Hi Tom,
>
> The max_power.py script runs just fine. However, the problem still
> seems to persists in general with other examples. I'm posting the
> error while running digital_bert_tx.py below. It exists for the rx
> example as well. In fact, with the latest version of gnuradio and uhd,
> even the uhd_fft.py as stopped working. This was working previously
> and would occasionally error out. Posting the error message below. It
> seems the problem is rooted deeper than the top level modules.
>
> My hardware is USRP2 (rev 4.0) with the XCVR2450 daughterboard. The
> host machine is a Dell Optiplex 980.
> Software versions are GNURadio (29aa72d4 - downloaded 1/30), UHD
> (e30cf4ec - downloaded 1/30), Firmware (003.004.000-322fb97), Ubuntu
> (10.04 - 32bit)
>
> If you need any more information, please let me know. I will try to
> debug this further. Please let me know if you have any suggestions in
> that direction.
>
> I'm really sorry for the delayed response. As I mentioned, I got
> absorbed into some other work.
>
> Thanks for your help.
>
> Shalabh
>
In the case of uhd_fft.py, what parameters are you passing on the
command line?


Just the frequency option (-f 2440M).

-Shalabh

[Discuss-gnuradio] Field test on Nokia 8890

Hello, all...

In trying to enable netmonitor on nokia 8890 with irda, but nothing happen.

Gnokii config:

[global]
port = /dev/ircomm0
model = AT
connection = irda
[logging]
debug = on
 
when i try to enable:
 
root@ruyi-Satellite-L645D:~/.config/gnokii# gnokii --netmonitor field
GNOKII Version 0.6.30
LOG: debug mask is 0x1
Config read from file /home/ruyi/.config/gnokii/config.
phone instance config:
model = AT
port = /dev/ircomm0
connection = irda
initlength = default
serial_baudrate = 19200
serial_write_usleep = -1
handshake = software
require_dcd = 0
smsc_timeout = 10
rfcomm_channel = 0
sm_retry = 0
Initializing AT capable mobile phone ...
Serial device: opening device /dev/ircomm0
Expecting:
Default: Nokia 8890 a71d0000
Message sent: 0x00 / 0x0004
41 54 5a 0d | ATZ
write: [ATZ<cr>]
Message sent: 0x00 / 0x0005
41 54 45 31 0d | ATE1
write: [ATE1<cr>]
Message sent: 0x00 / 0x000a
41 54 2b 43 4d 45 45 3d 31 0d | AT+CMEE=1
write: [AT+CMEE=1<cr>]
 
But nothing happen in the phone, i dont see the netmonitor menu.. 
 
Can anybody help me?
 
Thank in advance
Regards
Cristian
 
 

Re: [Discuss-gnuradio] Error while running std examples max_power.py, bert : boost::math::round(d): Value -nan

On 30/01/12 09:36 PM, Shalabh Jain wrote:
>
> Hi Tom,
>
> The max_power.py script runs just fine. However, the problem still
> seems to persists in general with other examples. I'm posting the
> error while running digital_bert_tx.py below. It exists for the rx
> example as well. In fact, with the latest version of gnuradio and uhd,
> even the uhd_fft.py as stopped working. This was working previously
> and would occasionally error out. Posting the error message below. It
> seems the problem is rooted deeper than the top level modules.
>
> My hardware is USRP2 (rev 4.0) with the XCVR2450 daughterboard. The
> host machine is a Dell Optiplex 980.
> Software versions are GNURadio (29aa72d4 - downloaded 1/30), UHD
> (e30cf4ec - downloaded 1/30), Firmware (003.004.000-322fb97), Ubuntu
> (10.04 - 32bit)
>
> If you need any more information, please let me know. I will try to
> debug this further. Please let me know if you have any suggestions in
> that direction.
>
> I'm really sorry for the delayed response. As I mentioned, I got
> absorbed into some other work.
>
> Thanks for your help.
>
> Shalabh
>
In the case of uhd_fft.py, what parameters are you passing on the
command line?


--
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] Error while running std examples max_power.py, bert : boost::math::round(d): Value -nan

On Mon, Jan 16, 2012 at 10:13 AM, Tom Rondeau <trondeau1122@gmail.com> wrote:
On Sun, Jan 15, 2012 at 11:32 PM, Tom Rondeau <trondeau1122@gmail.com> wrote:
On Fri, Jan 6, 2012 at 12:47 AM, Shalabh Jain <shalabh.jain@gmail.com> wrote:
Hello,

I recently installed the latest git pull of both the GNU Radio and UHD driver. I am getting the some relating to USRP initialization errors when I'm running some of the examples provided. max_power.py and digital_bert_tx.py or rx.py. 
My setup seems correct since I can run the fft scripts etc.

It seems to be some kind of overflow that is causing this but I am not able to figure out why. I tried to use my limited debugging skills and have these comments

1. Since bert is similar to the benchmark_tx, on comparing the two, I see that in digital_bert_tx, the error goes away if you comment out 
self._modulator = self._modulator_class(**mod_kwargs)
and pass 
self._modulator_class(**mod_kwargs)._constellation 
to the bert transmitter chain initialization. 

2. There is a minor mismatch in the arguments to the uhd_transmitter initialization, a subdevice is expected between options.tx_gain and options.antenna. 
But that is certainly not causing the error.

3. Looking at the C++ source code, the line of code that is actually throwing the exception is in the UHD tree (Line 152 in the uhd_src/host/lib/device.cpp)
device::sptr dev = maker(dev_addr);

I'll look into this tomorrow. When we moved everything to gr-digital and all of the examples to using UHD, we were moving quickly, and this might have been left behind after some change. I know it was working when I first added it. It looks like you found the fix; I'll verify it tomorrow.

 
4. I cannot figure out any temporary fix for the max_power.py failure.

I was debating over whether or not to even include this example when we moved to using the UHD. This was a program only designed for the first gen USRPs and libusrp. It's really probably not applicable to the conditions under the UHD anymore, anyway. Again, I'll check it tomorrow.
 
Has anybody else faced similar issues before or have any suggestions for debugging directions?

Thanks
Shalabh


Thanks for the feedback!

Tom

 
Traceback (most recent call last): - From bert
  File "./digital_bert_tx.py", line 130, in <module>
    tb = tx_psk_block(mod, options)
  File "./digital_bert_tx.py", line 73, in __init__
    options.antenna, options.verbose)
  File "/home/gnuradio/Shared/sj/usrp_stuff/code/s_eg/digital/narrowband/uhd_interface.py", line 137, in __init__
    freq, gain, spec, antenna)
  File "/home/gnuradio/Shared/sj/usrp_stuff/code/s_eg/digital/narrowband/uhd_interface.py", line 49, in __init__
    self.u = uhd.usrp_sink(device_addr=args, stream_args=uhd.stream_args('fc32'))
  File "/opt/gnuradio-3.5/lib/python2.6/dist-packages/gnuradio/uhd/__init__.py", line 112, in constructor_interceptor
    return old_constructor(*args)
  File "/opt/gnuradio-3.5/lib/python2.6/dist-packages/gnuradio/uhd/uhd_swig.py", line 2320, in usrp_sink
    return _uhd_swig.usrp_sink(*args)
RuntimeError: Error in function boost::math::round<d>(d): Value -nan can not be represented in the target integer type.



Traceback (most recent call last): - From max_power.py
  File "./max_power.py", line 140, in <module>
    main ()
  File "./max_power.py", line 133, in main
    tb = build_block (options.args, options.tx_enable, options.rx_enable)
  File "./max_power.py", line 63, in __init__
    self.u_tx = uhd.usrp_sink(device_addr=args, stream_args=stream_args)
  File "/opt/gnuradio-3.5/lib/python2.6/dist-packages/gnuradio/uhd/__init__.py", line 112, in constructor_interceptor
    return old_constructor(*args)
  File "/opt/gnuradio-3.5/lib/python2.6/dist-packages/gnuradio/uhd/uhd_swig.py", line 2320, in usrp_sink
    return _uhd_swig.usrp_sink(*args)
RuntimeError: Error in function boost::math::round<d>(d): Value -nan can not be represented in the target integer type.


Shalabh,

I just pushed fixes to the digital BER tests. It was indeed a case that some things changed with how the UHD interface was used that did not get updated here. I just tested these over the air successfully.

I was able to run the max_power.py script just fine. Can you post your hardware configuration so I can see if there is something specific there that's causing a problem?

Thanks,
Tom
 

Hi Tom,

The max_power.py script runs just fine. However, the problem still seems to persists in general with other examples. I'm posting the error while running digital_bert_tx.py below. It exists for the rx example as well. In fact, with the latest version of gnuradio and uhd, even the uhd_fft.py as stopped working. This was working previously and would occasionally error out. Posting the error message below. It seems the problem is rooted deeper than the top level modules.

My hardware is USRP2 (rev 4.0) with the XCVR2450 daughterboard. The host machine is a Dell Optiplex 980.
Software versions are GNURadio (29aa72d4 - downloaded 1/30), UHD (e30cf4ec - downloaded 1/30), Firmware (003.004.000-322fb97), Ubuntu (10.04 - 32bit)

If you need any more information, please let me know. I will try to debug this further. Please let me know if you have any suggestions in that direction.

I'm really sorry for the delayed response. As I mentioned, I got absorbed into some other work.

Thanks for your help.

Shalabh

linux; GNU C++ version 4.4.3; Boost_104000; UHD_003.004.000-e30cf4e
>>> gr_fir_ccf: using SSE
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
Traceback (most recent call last):
  File "./digital_bert_tx.py", line 133, in <module>
    tb = tx_psk_block(mod, options)
  File "./digital_bert_tx.py", line 75, in __init__
    options.antenna, options.verbose)
  File "/home/gnuradio/Shared/sj/usrp_stuff/code/s_eg/digital/narrowband/uhd_interface.py", line 137, in __init__
    freq, gain, spec, antenna)
  File "/home/gnuradio/Shared/sj/usrp_stuff/code/s_eg/digital/narrowband/uhd_interface.py", line 49, in __init__
    self.u = uhd.usrp_sink(device_addr=args, stream_args=uhd.stream_args('fc32'))
  File "/opt/gnuradio-3.5/lib/python2.6/dist-packages/gnuradio/uhd/__init__.py", line 112, in constructor_interceptor
    return old_constructor(*args)
  File "/opt/gnuradio-3.5/lib/python2.6/dist-packages/gnuradio/uhd/uhd_swig.py", line 2324, in usrp_sink
    return _uhd_swig.usrp_sink(*args)
RuntimeError: Error in function boost::math::round<d>(d): Value -nan can not be represented in the target integer type.



linux; GNU C++ version 4.4.3; Boost_104000; UHD_003.004.000-e30cf4e
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
Traceback (most recent call last):
  File "/opt/gnuradio-3.5/bin/uhd_fft.py", line 297, in <module>
    main ()
  File "/opt/gnuradio-3.5/bin/uhd_fft.py", line 293, in main
    app = stdgui2.stdapp(app_top_block, "UHD FFT", nstatus=1)
  File "/opt/gnuradio-3.5/lib/python2.6/dist-packages/gnuradio/wxgui/stdgui2.py", line 38, in __init__
    wx.App.__init__ (self, redirect=False)
  File "/usr/lib/python2.6/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py", line 7978, in __init__
    self._BootstrapApp()
  File "/usr/lib/python2.6/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py", line 7552, in _BootstrapApp
    return _core_.PyApp__BootstrapApp(*args, **kwargs)
  File "/opt/gnuradio-3.5/lib/python2.6/dist-packages/gnuradio/wxgui/stdgui2.py", line 42, in OnInit
    self._max_noutput_items)
  File "/opt/gnuradio-3.5/lib/python2.6/dist-packages/gnuradio/wxgui/stdgui2.py", line 64, in __init__
    self.panel = stdpanel (self, self, top_block_maker, max_nouts)
  File "/opt/gnuradio-3.5/lib/python2.6/dist-packages/gnuradio/wxgui/stdgui2.py", line 86, in __init__
    self.top_block = top_block_maker (frame, self, vbox, sys.argv)
  File "/opt/gnuradio-3.5/bin/uhd_fft.py", line 90, in __init__
    otw_format=options.wire_format, args=scalar))
  File "/opt/gnuradio-3.5/lib/python2.6/dist-packages/gnuradio/uhd/__init__.py", line 112, in constructor_interceptor
    return old_constructor(*args)
  File "/opt/gnuradio-3.5/lib/python2.6/dist-packages/gnuradio/uhd/uhd_swig.py", line 2290, in usrp_source
    return _uhd_swig.usrp_source(*args)
RuntimeError: Error in function boost::math::round<d>(d): Value -nan can not be represented in the target integer type.

[Discuss-gnuradio] Restore USRP2 images to support old USRP2 (Not UHD) code

Hi All,

I have burned the USRP2 to support the UHD, but now I need to run some old USRP2 code.
The new burned USRP2 images don't support the old code. So, is there any ways I can restore 
USRP2 images to old version to support the old code?

Any help is appreciated, thanks in advance.

--
Wenbo

Re: [Discuss-gnuradio] Problem finding gnuradio libraries on Mac OSX 10.6

I followed your advice, cleared everything out and started from scratch. Installing to /usr/local from my home directory appears to work (both dial_tone.py and my usrp B100) once I got my PYTHONPATH pointing in the right direction.

For any total newbies out there (like me) running cmake with -LAH helped a lot to get things pointed to the right libraries and directories.

Thanks again for the help.

On , Michael Dickens <mlk@alum.mit.edu> wrote:
> Hi Scott - You shouldn't need to set the DYLD path.  Have you verified that the file "/opt/local/lib/libgnuradio-core.3.5.2git.dylib" exists?  Did you use /opt/local for the MacPorts install?  I would -highly- recommend keeping MacPorts and any local installs separate -- e.g., use /opt/local for MacPorts and /usr/local for anything installed by hand.  You shouldn't need to do "sudo make" to get everything to compile, no matter if using CMake or GNU Autotools.  All of this says to me that your OS install is odd. - MLD
>
>
>
> On Jan 29, 2012, at 9:53 PM, Scott Kovaleski wrote:
>
>
>
> > Hello,
>
> >
>
> > I am very new to gnuradio, and I have been trying to build gnuradio on Mac OSX 10.6.8 on a 2.4 GHz Intel Core Duo Macbook Pro. I tried the Macports gnuradio, and it worked for me, but I couldn't get it to work with UHD which (I think) I need for my B100 USRP.
>
> >
>
> > I installed the dependencies from Macports. I downloaded gnuradio from git into /opt. I run cmake in /opt/gnuradio/build with the following options:
>
> >
>
> > sudo cmake -LAH -DCMAKE_INSTALL_PREFIX=/opt/local \
>
> > -DQWT_LIBRARIES=/opt/local/lib/libqwt.dylib \
>
> > -DQWT_INCLUDE_DIRS=/opt/local/include/qwt \
>
> > -DCMAKE_MAKE_PROGRAM=/usr/bin/make \
>
> > -DPYTHON_EXECUTABLE=/opt/local/bin/python2.6 \
>
> > -DPYTHON_LIBRARY=/opt/local/lib/libpython2.6.dylib \
>
> > -DPYTHON_INCLUDE_DIR=/opt/local/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6 \
>
> > ../
>
> >
>
> > then sudo make, then sudo make test (all but one test passes). Not sure if it's important, but I must use sudo even for cmake and make
>
> >
>
> > When I try to run dial_tone, however, I get the following:
>
> >
>
> > /opt/local/share/gnuradio/examples/audio> ./dial_tone.py
>
> > Traceback (most recent call last):
>
> >   File "./dial_tone.py", line 24, in
>
> >     from gnuradio import gr
>
> >   File "/opt/local/lib/python2.6/site-packages/gnuradio/gr/__init__.py", line 43, in
>
> >     from gnuradio_core import *
>
> >   File "/opt/local/lib/python2.6/site-packages/gnuradio/gr/gnuradio_core.py", line 23, in
>
> >     from gnuradio_core_runtime import *
>
> >   File "/opt/local/lib/python2.6/site-packages/gnuradio/gr/gnuradio_core_runtime.py", line 26, in
>
> >     _gnuradio_core_runtime = swig_import_helper()
>
> >   File "/opt/local/lib/python2.6/site-packages/gnuradio/gr/gnuradio_core_runtime.py", line 22, in swig_import_helper
>
> >     _mod = imp.load_module('_gnuradio_core_runtime', fp, pathname, description)
>
> > ImportError: dlopen(/opt/local/lib/python2.6/site-packages/gnuradio/gr/_gnuradio_core_runtime.so, 2): Library not loaded: libgnuradio-core.3.5.2git.dylib
>
> >   Referenced from: /opt/local/lib/python2.6/site-packages/gnuradio/gr/_gnuradio_core_runtime.so
>
> >   Reason: image not found
>
> >
>
> > When I run gnuradio-companion, I get an error window that says I should check PYTHONPATH and LD_LIBRARY_PATH which are set in my .profile to be the following:
>
> >
>
> > export PYTHONPATH=/opt/local/lib/python2.6/site-packages:/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/:$PYTHONPATH
>
> >
>
> > export LD_LIBRARY_PATH=/opt/local/lib:$LD_LIBRARY_PATH
>
> >
>
> > I am at a loss at this point, and I would be grateful for any help.
>
> >
>
> > Regards,
>
> >
>
> > Scott
>
> > _______________________________________________
>
> > Discuss-gnuradio mailing list
>
> > Discuss-gnuradio@gnu.org
>
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
>

Re: [Discuss-gnuradio] reg overrun problem

On 01/30/2012 09:41 AM, shantharam balasubramanian wrote:
> Hi
>
> I was trying to run the benchmark_rx and benchmark_tx programs in the
> gnuradio 3.5.0 version, in my college lab. But I saw that when I am running
> the benchmark_rx in one of the wireless nodes, it shows the 'O'.
>
> there are core i7 processors in the nodes, and I am not sure why this
> overrun problem is occurring. Can anyone tell me why this error occurs and
> what I should do to overcome it?
>
>

Ahh, le benchmark. Its more a proof of concept that you can implement a
mac layer in gnuradio, and less so a benchmark of anything. :-)

Here is a description of overflow:
http://files.ettus.com/uhd_docs/manual/html/general.html#overflow-underflow-notes

Faster processing can help, better code can help (if you care to
optimize benchmark rx*), and if you have a network product, larger
socket buffer can help:
http://files.ettus.com/uhd_docs/manual/html/transport.html#resize-socket-buffers

Not sure what modulation you selected, I think there may have been a
weird issue with the FLL. Try the GMSK modulation option (which doesnt
use the FLL), and see how well it works for you.

If you are feeling adventurous, I have SIMD-optimized float
adder/multiplier on my "next" branch. I think there are a few of these
multiplier blocks in the path of benchmark rx. So I am curious to hear
of the performance improvement of said math blocks provides any
noticeable effect for you in the overall benchmark rx app.
http://gnuradio.org/cgit/jblum.git/

Cheers,
-Josh

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

[Discuss-gnuradio] reg overrun problem

Hi

I was trying to run the benchmark_rx and benchmark_tx programs in the gnuradio 3.5.0 version, in my college lab. But I saw that when I am running the benchmark_rx in one of the wireless nodes, it shows the 'O'.

there are core i7 processors in the nodes, and I am not sure why this overrun problem is occurring. Can anyone tell me why this error occurs and what I should do to overcome it?


Thanks




--
Regards

Shantharam Balasubramanian
MS in Electrical and Computer Engineering
Rutgers University
Ph:732-543-6863
Email:shantharampsg@gmail.com

[Discuss-gnuradio] Quetion regarding crc checks .

Dear all,
    I am currently working on a gnuradio project and i was wondering if anybody could please share some information about how crc checks are made. As in when one makes a crc32 call from ones python script , in crc.py it says the following

crc = digital_swig.crc32(s)

and there after it makes a call to _digital_swig.crc32. I dont fully understand the "behind the scene operation" of "_digital_swig" . I understand that its a library associated file but its operation is what i cannot fully comprehend. Does it help make a call to digital_crc32.cc file which has all the underlying code.

I would be awfully obliged if somebody were to spare sometime and help out in this regard.

Thanks,
Anay.

Re: [Discuss-gnuradio] Running tunnel.py/benchmark_tx.py (OFDM) with XCVR2450?

On Mon, Jan 30, 2012 at 04:11:05PM +0100, Florian Schlembach wrote:
> We have now extended our tests to the tests with two USRP2s with
> daughterboards: Neither the benchmark_tx.py example nor the tunnel.py is
> receiving any packets. We checked the spectrum and tuned the gains as well.
> (OFDM)
>
> Now, we played with the benchmark files and tunnel.py located in the narrowband
> folder and therefore changed the modulation scheme from BPSK to GMSK and
> ultimately receiving all the packets!! That's strange.
>
> Does anybody knows what code be the problem that we can't establish any
> connection using higher order modulation schemes? Could it possibly be our
> slightly outdated UHD version?
>
> We are totally clueless, so we appreciate any idea/help!

This won't really help, but I remember we had exactly the same troubles here.
This was before UHD was even released, so I doubt that's the reason.
Unfortunately, I can't remember how (or: if) we fixed it :( but I'll
keep you updated if my memory comes up with something.

But fiddling with gain values is often useful; even if you've already
done that I recommend trying again, by reducing tx-amplitude and the
actual gain values, shifting the terminals around (perhaps they're too
close?).

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

Re: [Discuss-gnuradio] Running tunnel.py/benchmark_tx.py (OFDM) with XCVR2450?

We have now extended our tests to the tests with two USRP2s with daughterboards: Neither the benchmark_tx.py example nor the tunnel.py is receiving any packets. We checked the spectrum and tuned the gains as well. (OFDM)

Now, we played with the benchmark files and tunnel.py located in the narrowband folder and therefore changed the modulation scheme from BPSK to GMSK and ultimately receiving all the packets!! That's strange.

Does anybody knows what code be the problem that we can't establish any connection using higher order modulation schemes? Could it possibly be our slightly outdated UHD version?

We are totally clueless, so we appreciate any idea/help!

Am 25.01.2012 18:02 schrieb <discuss-gnuradio-request@gnu.org>:
Send Discuss-gnuradio mailing list submissions to
       discuss-gnuradio@gnu.org

To subscribe or unsubscribe via the World Wide Web, visit
       https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
or, via email, send a message with subject or body 'help' to
       discuss-gnuradio-request@gnu.org

You can reach the person managing the list at
       discuss-gnuradio-owner@gnu.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Discuss-gnuradio digest..."


Today's Topics:

  1. Re: Try to improve E100's performance at high sample rate (ziyang)
  2. Re: Try to improve E100's performance at high sample rate
     (Nick Foster)
  3. Re: Try to improve E100's performance at high sample rate
     (Evan Merewether)
  4. Re: Try to improve E100's performance at high sample rate
     (Almohanad Fayez)
  5. Re: Try to improve E100's performance at high sample rate (ziyang)
  6. Changing the value of a Python Variable into a    block (Andr? Selva)
  7. Re: Changing the value of a Python Variable into a block
     (Josh Blum)
  8.  GNURadio and Parrallel Computing (Alex Zhang)
  9. Re: GNURadio and Parrallel Computing (Alex Zhang)
 10. Re: Try to improve E100's performance at high sample rate
     (Philip Balister)
 11. Re: GNURadio and Parrallel Computing (Tom Rondeau)
 12. Running tunnel.py/benchmark_tx.py (OFDM) with     XCVR2450?
     (Florian Schlembach)


----------------------------------------------------------------------

Message: 1
Date: Tue, 24 Jan 2012 18:56:09 +0100
From: ziyang <ziyang@sics.se>
To: Nick Foster <nick@ettus.com>
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Try to improve E100's performance at
       high sample rate
Message-ID: <4F1EF0B9.7040209@sics.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 01/19/2012 07:13 PM, Nick Foster wrote:
> Optimizing an algorithm is a hard and sometimes counterintuitive
> process. You might benchmark the following:
>
> - Gnuradio's atan2 WITHOUT any Volk multiplications (just comment out
> the volk mults in your block)
> - The Volk multiplications WITHOUT Gnuradio's atan2 (just comment out
> the atan2 in your block)
>
> This will let you determine where the bottleneck is. In addition, try
> running over a MUCH larger dataset. The clock resolution at <1ms is
> not very good and the scheduler will have a correspondingly larger
> effect at smaller timescales.
>
> I think you'll find the atan2 part takes vastly longer than the
> multiplications do, and that will be where you have to look for
> performance improvements.
>
> --n
>


Hi Nick,

I have been doing some tests about the demodulation module. As you said,
the atan2 part takes much longer than the multiplication. So in order to
maximize the performance improvement that volk could bring to the
processing, I took a division and a multiplication out of atan2, and use
volk-ified divider and multiplier instead. Then I run tests using a much
larger dataset.

But from the test results, I did not observe a performance improvement.
In fact, the average processing time even increase a little bit. So I
was wondering if what I did was not a good way to improve the performance?

Another issue is that when I ran Cmake to build Gnuradio on E100, it
reported this:
-- Available arches: generic;neon
-- Available machines: generic;neon
-- Did not find liborc and orcc, disabling orc support...

But from the "opkg list-installed | grep orc" check, both orc and liborc
are installed. Could this lack of orc support be part of the reason why
my implementation did not have a performance improvement?

I will appreciate it if you could give me a hand on this. Thanks.


Best Regards,

Terry







------------------------------

Message: 2
Date: Tue, 24 Jan 2012 10:12:34 -0800
From: Nick Foster <nick@ettus.com>
To: ziyang <ziyang@sics.se>
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Try to improve E100's performance at
       high sample rate
Message-ID:
       <CALALHJUO8FdW8mXsTt7KZ-gPQ-ooBxo=5gFCVYJeS22fSUsLAg@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

On Tue, Jan 24, 2012 at 9:56 AM, ziyang <ziyang@sics.se> wrote:

> On 01/19/2012 07:13 PM, Nick Foster wrote:
>
>> Optimizing an algorithm is a hard and sometimes counterintuitive process.
>> You might benchmark the following:
>>
>> - Gnuradio's atan2 WITHOUT any Volk multiplications (just comment out the
>> volk mults in your block)
>> - The Volk multiplications WITHOUT Gnuradio's atan2 (just comment out the
>> atan2 in your block)
>>
>> This will let you determine where the bottleneck is. In addition, try
>> running over a MUCH larger dataset. The clock resolution at <1ms is not
>> very good and the scheduler will have a correspondingly larger effect at
>> smaller timescales.
>>
>> I think you'll find the atan2 part takes vastly longer than the
>> multiplications do, and that will be where you have to look for performance
>> improvements.
>>
>> --n
>>
>>
>
> Hi Nick,
>
> I have been doing some tests about the demodulation module. As you said,
> the atan2 part takes much longer than the multiplication. So in order to
> maximize the performance improvement that volk could bring to the
> processing, I took a division and a multiplication out of atan2, and use
> volk-ified divider and multiplier instead. Then I run tests using a much
> larger dataset.
>
> But from the test results, I did not observe a performance improvement. In
> fact, the average processing time even increase a little bit. So I was
> wondering if what I did was not a good way to improve the performance?
>
> Another issue is that when I ran Cmake to build Gnuradio on E100, it
> reported this:
> -- Available arches: generic;neon
> -- Available machines: generic;neon
> -- Did not find liborc and orcc, disabling orc support...
>
> But from the "opkg list-installed | grep orc" check, both orc and liborc
> are installed. Could this lack of orc support be part of the reason why my
> implementation did not have a performance improvement?
>

Very likely. Make sure that orcc is somewhere that pkgconfig can find it,
and make sure its version is > 0.4.10.


>
> I will appreciate it if you could give me a hand on this. Thanks.
>
>
> Best Regards,
>
> Terry
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120124/e956f4f9/attachment.html>

------------------------------

Message: 3
Date: Tue, 24 Jan 2012 11:22:20 -0700
From: "Evan Merewether" <evan@syndetix.com>
To: <discuss-gnuradio@gnu.org>
Subject: Re: [Discuss-gnuradio] Try to improve E100's performance at
       high sample rate
Message-ID: <FECC3CC5287047F2A64B444AF9119D34@corp.syndetix.com>
Content-Type: text/plain; charset="us-ascii"

Has anybody looked at using the CORDIC approximation for atan2?  Depending
on the required accuracy, this may dramatically improve performance in your
C code.  Ultimately, you can implement the CORDIC functions in the FPGA
(quasi math-coprocessor style) which would then give you the fastest
possible computation speed.

Evan

-----Original Message-----
From: discuss-gnuradio-bounces+evan=syndetix.com@gnu.org
[mailto:discuss-gnuradio-bounces+evan=syndetix.com@gnu.org] On Behalf Of
ziyang
Sent: Tuesday, January 24, 2012 10:56 AM
To: Nick Foster
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Try to improve E100's performance at high
sample rate

On 01/19/2012 07:13 PM, Nick Foster wrote:
> Optimizing an algorithm is a hard and sometimes counterintuitive
> process. You might benchmark the following:
>
> - Gnuradio's atan2 WITHOUT any Volk multiplications (just comment out
> the volk mults in your block)
> - The Volk multiplications WITHOUT Gnuradio's atan2 (just comment out
> the atan2 in your block)
>
> This will let you determine where the bottleneck is. In addition, try
> running over a MUCH larger dataset. The clock resolution at <1ms is
> not very good and the scheduler will have a correspondingly larger
> effect at smaller timescales.
>
> I think you'll find the atan2 part takes vastly longer than the
> multiplications do, and that will be where you have to look for
> performance improvements.
>
> --n
>


Hi Nick,

I have been doing some tests about the demodulation module. As you said,
the atan2 part takes much longer than the multiplication. So in order to
maximize the performance improvement that volk could bring to the
processing, I took a division and a multiplication out of atan2, and use
volk-ified divider and multiplier instead. Then I run tests using a much
larger dataset.

But from the test results, I did not observe a performance improvement.
In fact, the average processing time even increase a little bit. So I
was wondering if what I did was not a good way to improve the performance?

Another issue is that when I ran Cmake to build Gnuradio on E100, it
reported this:
-- Available arches: generic;neon
-- Available machines: generic;neon
-- Did not find liborc and orcc, disabling orc support...

But from the "opkg list-installed | grep orc" check, both orc and liborc
are installed. Could this lack of orc support be part of the reason why
my implementation did not have a performance improvement?

I will appreciate it if you could give me a hand on this. Thanks.


Best Regards,

Terry





_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.1901 / Virus Database: 2109/4763 - Release Date: 01/24/12




------------------------------

Message: 4
Date: Tue, 24 Jan 2012 13:33:33 -0500 (EST)
From: Almohanad Fayez <alfayez@aol.com>
To: evan@syndetix.com, discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Try to improve E100's performance at
       high sample rate
Message-ID:
       <8CEA8DDCF91C50C-1D3C-23F27@webmail-stg-m02.sysops.aol.com>
Content-Type: text/plain; charset="us-ascii"

I haven't used VOLK with the OMAP processor but from my experience with the E100 every multiplication and/or division in your flowgraph counts ... When I was working on my C64x+ DSP based FM receiver on the E100 I was moving individual blocks 1-by-1 from the GPP to the DSP and almost every multiplication/division on the GPP caused a buffer overflow my impression at least is if you're going for a pure GPP implementation you need to make used of NEOS vector operations and if you're using a DSP based solution you'll need to find a way to speed up the GPP/DSP buffers, which is something I'm hoping to have more time to look into.




Almohanad Fayez
alfayez@aol.com





-----Original Message-----
From: Evan Merewether <evan@syndetix.com>
To: discuss-gnuradio <discuss-gnuradio@gnu.org>
Sent: Tue, Jan 24, 2012 1:22 pm
Subject: Re: [Discuss-gnuradio] Try to improve E100's performance at high sample rate


Has anybody looked at using the CORDIC approximation for atan2?  Depending

on the required accuracy, this may dramatically improve performance in your

C code.  Ultimately, you can implement the CORDIC functions in the FPGA

(quasi math-coprocessor style) which would then give you the fastest

possible computation speed.



Evan



-----Original Message-----

From: discuss-gnuradio-bounces+evan=syndetix.com@gnu.org

[mailto:discuss-gnuradio-bounces+evan=syndetix.com@gnu.org] On Behalf Of

ziyang

Sent: Tuesday, January 24, 2012 10:56 AM

To: Nick Foster

Cc: discuss-gnuradio@gnu.org

Subject: Re: [Discuss-gnuradio] Try to improve E100's performance at high

sample rate



On 01/19/2012 07:13 PM, Nick Foster wrote:

> Optimizing an algorithm is a hard and sometimes counterintuitive

> process. You might benchmark the following:

>

> - Gnuradio's atan2 WITHOUT any Volk multiplications (just comment out

> the volk mults in your block)

> - The Volk multiplications WITHOUT Gnuradio's atan2 (just comment out

> the atan2 in your block)

>

> This will let you determine where the bottleneck is. In addition, try

> running over a MUCH larger dataset. The clock resolution at <1ms is

> not very good and the scheduler will have a correspondingly larger

> effect at smaller timescales.

>

> I think you'll find the atan2 part takes vastly longer than the

> multiplications do, and that will be where you have to look for

> performance improvements.

>

> --n

>





Hi Nick,



I have been doing some tests about the demodulation module. As you said,

the atan2 part takes much longer than the multiplication. So in order to

maximize the performance improvement that volk could bring to the

processing, I took a division and a multiplication out of atan2, and use

volk-ified divider and multiplier instead. Then I run tests using a much

larger dataset.



But from the test results, I did not observe a performance improvement.

In fact, the average processing time even increase a little bit. So I

was wondering if what I did was not a good way to improve the performance?



Another issue is that when I ran Cmake to build Gnuradio on E100, it

reported this:

-- Available arches: generic;neon

-- Available machines: generic;neon

-- Did not find liborc and orcc, disabling orc support...



But from the "opkg list-installed | grep orc" check, both orc and liborc

are installed. Could this lack of orc support be part of the reason why

my implementation did not have a performance improvement?



I will appreciate it if you could give me a hand on this. Thanks.





Best Regards,



Terry











_______________________________________________

Discuss-gnuradio mailing list

Discuss-gnuradio@gnu.org

https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

-----

No virus found in this message.

Checked by AVG - www.avg.com

Version: 2012.0.1901 / Virus Database: 2109/4763 - Release Date: 01/24/12





_______________________________________________

Discuss-gnuradio mailing list

Discuss-gnuradio@gnu.org

https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120124/08c39673/attachment.html>

------------------------------

Message: 5
Date: Tue, 24 Jan 2012 19:43:10 +0100
From: ziyang <ziyang@sics.se>
To: Nick Foster <nick@ettus.com>
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Try to improve E100's performance at
       high sample rate
Message-ID: <4F1EFBBE.2020102@sics.se>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"

On 01/24/2012 07:12 PM, Nick Foster wrote:
> On Tue, Jan 24, 2012 at 9:56 AM, ziyang <ziyang@sics.se
> <mailto:ziyang@sics.se>> wrote:
>
>     On 01/19/2012 07:13 PM, Nick Foster wrote:
>
>         Optimizing an algorithm is a hard and sometimes
>         counterintuitive process. You might benchmark the following:
>
>         - Gnuradio's atan2 WITHOUT any Volk multiplications (just
>         comment out the volk mults in your block)
>         - The Volk multiplications WITHOUT Gnuradio's atan2 (just
>         comment out the atan2 in your block)
>
>         This will let you determine where the bottleneck is. In
>         addition, try running over a MUCH larger dataset. The clock
>         resolution at <1ms is not very good and the scheduler will
>         have a correspondingly larger effect at smaller timescales.
>
>         I think you'll find the atan2 part takes vastly longer than
>         the multiplications do, and that will be where you have to
>         look for performance improvements.
>
>         --n
>
>
>
>     Hi Nick,
>
>     I have been doing some tests about the demodulation module. As you
>     said, the atan2 part takes much longer than the multiplication. So
>     in order to maximize the performance improvement that volk could
>     bring to the processing, I took a division and a multiplication
>     out of atan2, and use volk-ified divider and multiplier instead.
>     Then I run tests using a much larger dataset.
>
>     But from the test results, I did not observe a performance
>     improvement. In fact, the average processing time even increase a
>     little bit. So I was wondering if what I did was not a good way to
>     improve the performance?
>
>     Another issue is that when I ran Cmake to build Gnuradio on E100,
>     it reported this:
>     -- Available arches: generic;neon
>     -- Available machines: generic;neon
>     -- Did not find liborc and orcc, disabling orc support...
>
>     But from the "opkg list-installed | grep orc" check, both orc and
>     liborc are installed. Could this lack of orc support be part of
>     the reason why my implementation did not have a performance
>     improvement?
>
>
> Very likely. Make sure that orcc is somewhere that pkgconfig can find
> it, and make sure its version is > 0.4.10.

This is what it shows when I run a "opkg list-installed | grep orc" check:

liborc-0.4-0 - 0.4.16-r1.0.9
liborc-test-0.4-0 - 0.4.16-r1.0.9
orc - 0.4.16-r1.0.9

I don't understand why orc/liborc cannot be detected by CMake. The
options for CMake are:

cmake -DCMAKE_INSTALL_PREFIX=/usr
-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" ../

Could you tell me what might be the problem? Thanks.


Terry


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120124/0e9cf2ac/attachment.html>

------------------------------

Message: 6
Date: Tue, 24 Jan 2012 16:42:55 -0200
From: Andr? Selva <andrefselva@gmail.com>
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] Changing the value of a Python Variable
       into a  block
Message-ID:
       <CALC7W7=_WTAU1DV7RQ-8CHvFkT2H-kn1hiBtqhg1t9vQ9WQdzQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hello!

I'm developing a TV enconder, and I need to extract information from my
input data, and this will be used to determine the parameters of other
blocks on the flow graph.
How can I change the value of a variable of the python (or grc) environment
from the block general_work() method?

Thanks!

--
Andr? F. B. Selva -
SECOMP - Semana da Computa??o da Unicamp 2012
Coordenador Geral
CACo - Centro Acad?mico da Computa??o
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120124/f1bedf6d/attachment.html>

------------------------------

Message: 7
Date: Tue, 24 Jan 2012 11:31:14 -0800
From: Josh Blum <josh@joshknows.com>
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Changing the value of a Python
       Variable into a block
Message-ID: <4F1F0702.4030509@joshknows.com>
Content-Type: text/plain; charset=ISO-8859-1



On 01/24/2012 10:42 AM, Andr? Selva wrote:
> Hello!
>
> I'm developing a TV enconder, and I need to extract information from my
> input data, and this will be used to determine the parameters of other
> blocks on the flow graph.
> How can I change the value of a variable of the python (or grc) environment
> from the block general_work() method?
>

Well, you generally cant call a python function from c++.... but heres a
few ways that may accomplish what you need:

1) Using swig directors is a possibility. Rather than figure out the
intricacies of directors, gnuradio already makes use of them in the
gr.feval_* class, which you can use to call into a python object. Your
general_work() calls the feval object in c++; and then feval object
(from python) directly calls into other variables in the python-domain
of your flow graph.

2) Another possibility is passing messages into a message queue object.
A python thread can pop the messages and act upon them.

3) A related possibility, depending upon how your block operates would
be to have a python thread periodically poll the getter methods of your
custom block and act upon those values. There is already a block in grc
that will poll another block's getter function and update a variable.

4) You could write the general work in python, which means all of the
parameter calculation and setting occurs entirely in python (this
functionality is not yet officially accepted).
http://gnuradio.org/redmine/projects/gnuradio/wiki/WriteBlocksInPython

5) And if thats not possible for performance reasons, you might consider
a hybrid approach where you write general work in python, but you call
into a function implemented in c++; where this function processes the
input data and returns the "determined parameters", which you can act on
in python.

-Josh



------------------------------

Message: 8
Date: Tue, 24 Jan 2012 14:55:55 -0600
From: Alex Zhang <cingular.alex@gmail.com>
To: gnuradio mailing list <discuss-gnuradio@gnu.org>
Subject: [Discuss-gnuradio]  GNURadio and Parrallel Computing
Message-ID:
       <CA+FEAnfdiDkDUHR2G=UOwHhL+1qM=XRnu4x0Z8umGcp5L0JosQ@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"

Hi,

We want to fully utilize the multi-core/GPU archtecture to implement the
GNURadio based signal processing flow.
Are there any official materials summarizing the usage for the so-called
TPB (thread-per-block) mechanism in the GNURadio community? Or related
papers are also appreciated.

--

Alex,
*Dreams can come true ? just believe.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120124/1f0e3fdc/attachment.html>

------------------------------

Message: 9
Date: Tue, 24 Jan 2012 15:00:38 -0600
From: Alex Zhang <cingular.alex@gmail.com>
To: gnuradio mailing list <discuss-gnuradio@gnu.org>
Subject: Re: [Discuss-gnuradio] GNURadio and Parrallel Computing
Message-ID:
       <CA+FEAndiOSK1FzAOc0kzcj0oRTUza0u9=QGvHVZTn5HqzmxbmQ@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"

And I remember that
Eric Blossom<http://dl.acm.org/author_page.cfm?id=81100473842&coll=DL&dl=ACM&trk=0&cfid=63471391&cftoken=37521642>
has a paper describing the GNURadio scheduler on parallel architecture. But
I don't remember the paper name.

On Tue, Jan 24, 2012 at 2:55 PM, Alex Zhang <cingular.alex@gmail.com> wrote:

> Hi,
>
> We want to fully utilize the multi-core/GPU archtecture to implement the
> GNURadio based signal processing flow.
> Are there any official materials summarizing the usage for the so-called
> TPB (thread-per-block) mechanism in the GNURadio community? Or related
> papers are also appreciated.
>
> --
>
> Alex,
> *Dreams can come true ? just believe.*
>
>


--

Alex,
*Dreams can come true ? just believe.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120124/6d2eaf80/attachment.html>

------------------------------

Message: 10
Date: Tue, 24 Jan 2012 17:00:56 -0500
From: Philip Balister <philip@balister.org>
To: ziyang <ziyang@sics.se>
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Try to improve E100's performance at
       high sample rate
Message-ID: <4F1F2A18.7020009@balister.org>
Content-Type: text/plain; charset=ISO-8859-1

On 01/24/2012 01:43 PM, ziyang wrote:
> On 01/24/2012 07:12 PM, Nick Foster wrote:
>> On Tue, Jan 24, 2012 at 9:56 AM, ziyang <ziyang@sics.se
>> <mailto:ziyang@sics.se>> wrote:
>>
>>     On 01/19/2012 07:13 PM, Nick Foster wrote:
>>
>>         Optimizing an algorithm is a hard and sometimes
>>         counterintuitive process. You might benchmark the following:
>>
>>         - Gnuradio's atan2 WITHOUT any Volk multiplications (just
>>         comment out the volk mults in your block)
>>         - The Volk multiplications WITHOUT Gnuradio's atan2 (just
>>         comment out the atan2 in your block)
>>
>>         This will let you determine where the bottleneck is. In
>>         addition, try running over a MUCH larger dataset. The clock
>>         resolution at <1ms is not very good and the scheduler will
>>         have a correspondingly larger effect at smaller timescales.
>>
>>         I think you'll find the atan2 part takes vastly longer than
>>         the multiplications do, and that will be where you have to
>>         look for performance improvements.
>>
>>         --n
>>
>>
>>
>>     Hi Nick,
>>
>>     I have been doing some tests about the demodulation module. As you
>>     said, the atan2 part takes much longer than the multiplication. So
>>     in order to maximize the performance improvement that volk could
>>     bring to the processing, I took a division and a multiplication
>>     out of atan2, and use volk-ified divider and multiplier instead.
>>     Then I run tests using a much larger dataset.
>>
>>     But from the test results, I did not observe a performance
>>     improvement. In fact, the average processing time even increase a
>>     little bit. So I was wondering if what I did was not a good way to
>>     improve the performance?
>>
>>     Another issue is that when I ran Cmake to build Gnuradio on E100,
>>     it reported this:
>>     -- Available arches: generic;neon
>>     -- Available machines: generic;neon
>>     -- Did not find liborc and orcc, disabling orc support...
>>
>>     But from the "opkg list-installed | grep orc" check, both orc and
>>     liborc are installed. Could this lack of orc support be part of
>>     the reason why my implementation did not have a performance
>>     improvement?
>>
>>
>> Very likely. Make sure that orcc is somewhere that pkgconfig can find
>> it, and make sure its version is > 0.4.10.
>
> This is what it shows when I run a "opkg list-installed | grep orc" check:
>
> liborc-0.4-0 - 0.4.16-r1.0.9
> liborc-test-0.4-0 - 0.4.16-r1.0.9
> orc - 0.4.16-r1.0.9
>
> I don't understand why orc/liborc cannot be detected by CMake. The
> options for CMake are:
>
> cmake -DCMAKE_INSTALL_PREFIX=/usr
> -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" ../
>
> Could you tell me what might be the problem? Thanks.

Add -DENABLE_ORC=ON to the cmake command line.

Philip

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



------------------------------

Message: 11
Date: Tue, 24 Jan 2012 17:12:57 -0500
From: Tom Rondeau <tom@trondeau.com>
To: Alex Zhang <cingular.alex@gmail.com>
Cc: gnuradio mailing list <discuss-gnuradio@gnu.org>
Subject: Re: [Discuss-gnuradio] GNURadio and Parrallel Computing
Message-ID:
       <CA+SzT6hAsnFrwo5rwuoPL6K=DfLAhbA_4p7WJ3tX1aCaCwx98w@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"

On Tue, Jan 24, 2012 at 4:00 PM, Alex Zhang <cingular.alex@gmail.com> wrote:

> And I remember that
> Eric Blossom<http://dl.acm.org/author_page.cfm?id=81100473842&coll=DL&dl=ACM&trk=0&cfid=63471391&cftoken=37521642>
> has a paper describing the GNURadio scheduler on parallel architecture.
> But I don't remember the paper name.
>
> On Tue, Jan 24, 2012 at 2:55 PM, Alex Zhang <cingular.alex@gmail.com>wrote:
>
>> Hi,
>>
>> We want to fully utilize the multi-core/GPU archtecture to implement the
>> GNURadio based signal processing flow.
>> Are there any official materials summarizing the usage for the so-called
>> TPB (thread-per-block) mechanism in the GNURadio community? Or related
>> papers are also appreciated.
>>
>> --
>>
>> Alex,
>> *Dreams can come true ? just believe.*
>>
>>  --
>
> Alex,
> *Dreams can come true ? just believe.*
>


Hi Alex,

Good project to work on. I don't know any papers on the TPB scheduler. If
Eric wrote one like you mentioned, I'm not sure where it would be :) If you
or someone else is aware of it, I'd love to get the reference so we can
link to it on our site (
http://gnuradio.org/redmine/projects/gnuradio/wiki/AcademicPapers)

In the meantime, I recommend looking at GRGPU and Will Plishker's work from
Univ. Maryland. He just made a CGRAN project out of it:
https://www.cgran.org/wiki/GRGPU

--
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120124/03d95061/attachment.html>

------------------------------

Message: 12
Date: Wed, 25 Jan 2012 16:18:17 +0100
From: Florian Schlembach <florian.schlembach@tu-ilmenau.de>
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] Running tunnel.py/benchmark_tx.py (OFDM)
       with    XCVR2450?
Message-ID:
       <CAMZjtuzj9fiXWFMLhZGX89sGgzpoTYF-bRM1gK7fD=q1z8KkVg@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Hey guys,

we are trying to get run the tunnel.py / benchmark_rx.py (OFDM) in order to
measure the datarate between two USRP2 (located with distance of 1 m) with
daughterboards XCVR2450.
We are running the benchmark_tx/rx.py as follows:

benchmark_tx.py -f 2.4G --tx-gain=10 --tx-amplitude=0.8 -v
benchmark_rx.py -f 2.4G --rx-gain=4 -v

We already tried to tune the parameters by analyzing the spectrum by
gnuradio-companion. It looks reasonable and the SNR is round about 20 dB
which should be fine?
Unfortunately, we don't get any packets transmitted. The RX side always
says TIMEOUT.

Our configuration is as follows:
- Ubuntu 10.04
- gnuradio 3.5.1 (installed freshly)
- UHD firmware version 003.003.001
- XCVR2450

Has anybody already got the tunnel.py/benchmark_tx.py run with a similar
configuration? Has anybody an idea what we are doing wrong?

Thanks in advance for your help! Best Regards, Florian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120125/83b837d9/attachment.html>

------------------------------

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


End of Discuss-gnuradio Digest, Vol 110, Issue 25
*************************************************