Re: [Discuss-gnuradio] Running gr-ieee 802.11 and gr-ieee 802.15.4 under same flowgraph (interference and co-existence)

[Bastian Bloessl]

Hi,
On 07/08/2017 07:11 PM, sumitstop wrote:

Wao superb! you cleaned it out also. Yes it works. Thanks much.

But did you figure out what was the issue at the first place :)


I'm not sure. Maybe it was related to one of the Packet Pad blocks. 
Since you resampled, you also changed the length of the frame, which 
might have confused the block (the length tag at the start of the frame 
didn't correspond to the length of the frame anymore).




I have another related question about the wireshark connector in
transceiver_OQPSK.grc. I see that wireshark connector gets input from two
different outputs.

One from pdu_out of IEEE802.15.4 MAC and another from rxout of IEEE802.15.4
OQPSK PHY

When I see the output pcap file i..e sensor.pcap, same packet is logged
twice. I realized this by observing their sequence number field, which
repeats two times for every broadcast frame.


Yes, in the loopback configuration it logs all frames twice. Once they 
are sent and once they are received. The setup makes more sense when you 
actually transmit frames over the air. Then you might want to log what 
was sent and what was received.


In your simulations you probably know what you sent and are only 
interested in which frames made it through. In that case, just remove 
the connection from the sender to the Wireshark block.


Best,
Bastian

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

Re: [Discuss-gnuradio] Running gr-ieee 802.11 and gr-ieee 802.15.4 under same flowgraph (interference and co-existence)

[sumitstop]

Wao superb! you cleaned it out also. Yes it works. Thanks much. 

But did you figure out what was the issue at the first place :) 

I have another related question about the wireshark connector in
transceiver_OQPSK.grc. I see that wireshark connector gets input from two
different outputs. 

One from pdu_out of IEEE802.15.4 MAC and another from rxout of IEEE802.15.4
OQPSK PHY 

When I see the output pcap file i..e sensor.pcap, same packet is logged
twice. I realized this by observing their sequence number field, which
repeats two times for every broadcast frame.
 
I have attached the pcap file for your reference. 
sensor.pcap   

I solved the issue by disconnecting one of the connectors but I am not sure
which one is correct. 
pdu_out of IEEE802.15.4 MAC should go to wireshark 
or 
rxout of IEEE802.15.4 OQPSK PHY should go to wireshark

Both of the above dump correct wireshark capture.

Regards
Sumit



 





--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Running-gr-ieee-802-11-and-gr-ieee-802-15-4-under-same-flowgraph-interference-and-co-existence-tp64474p64517.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

Re: [Discuss-gnuradio] Running gr-ieee 802.11 and gr-ieee 802.15.4 under same flowgraph (interference and co-existence)

[Bastian Bloessl]

Hi,

On 07/06/2017 07:55 AM, sumitstop wrote:

Hello Bastian,
Sorry for late response.
I am attaching the files for your reference. There are 2 grc files

1. wifi_zigbee.grc : wifi and zigbee loopbacks are running in parallel >>
works good

2. wifi_zigbee_interference.grc : Here I interpolate the zigbee output by 5,
feed to channel, add to 20 MHz wifi signal. Added signal is fed directly to
wifi receiver however I decimate it by 5 before feeding it to zigbee
receiver.

I see the following on the terminal for the 2nd grc file.

[INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800;
UHD_4.0.0.rfnoc-devel-283-g7ff43262
MAPPER: encoding: 0
set_min_output_buffer on block 9 to 397056
set_min_output_buffer on block 11 to 397056
set_min_output_buffer on block 13 to 397056
set_min_output_buffer on block 14 to 397056
set_min_output_buffer on block 16 to 397056
sender started
set_min_output_buffer on block 58 to 96000


After that nothing happens, just the cursor keeps blinking.

wifi_zigbee.grc


wifi_zigbee_interference.grc




I was playing a bit around with the flow graph. Forgot what the actual 
problem was, but this adapted version works for me:


http://www.ccs-labs.org/~bloessl/wifi_zigbee_interference.grc

Best,
Bastian

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

Re: [Discuss-gnuradio] Running gr-ieee 802.11 and gr-ieee 802.15.4 under same flowgraph (interference and co-existence)

[sumitstop]

Hello Bastian, 
Sorry for late response. 
I am attaching the files for your reference. There are 2 grc files 

1. wifi_zigbee.grc : wifi and zigbee loopbacks are running in parallel >>
works good

2. wifi_zigbee_interference.grc : Here I interpolate the zigbee output by 5,
feed to channel, add to 20 MHz wifi signal. Added signal is fed directly to
wifi receiver however I decimate it by 5 before feeding it to zigbee
receiver. 

I see the following on the terminal for the 2nd grc file.

[INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800;
UHD_4.0.0.rfnoc-devel-283-g7ff43262
MAPPER: encoding: 0
set_min_output_buffer on block 9 to 397056
set_min_output_buffer on block 11 to 397056
set_min_output_buffer on block 13 to 397056
set_min_output_buffer on block 14 to 397056
set_min_output_buffer on block 16 to 397056
sender started
set_min_output_buffer on block 58 to 96000


After that nothing happens, just the cursor keeps blinking.

wifi_zigbee.grc
  

wifi_zigbee_interference.grc
  



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Running-gr-ieee-802-11-and-gr-ieee-802-15-4-under-same-flowgraph-interference-and-co-existence-tp64474p64483.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

Re: [Discuss-gnuradio] Running gr-ieee 802.11 and gr-ieee 802.15.4 under same flowgraph (interference and co-existence)

[Bastian Bloessl]

Hi,

thanks for the detailed description. I’m not sure what the actual error is. 
What do you mean with grc turns dark.
Does it crash or stop receiving or actually show a black window? Did grc turn 
dark or the flow graph?

Best,
Bastian



> On 4. Jul 2017, at 22:10, sumitstop  wrote:
> 
> Hello, 
> (Its a long post :) as I want to give as much details as possible)
> 
> Today I did a strange experiment. Under GNU Radio companion, I created a
> blank project. Then I copy pasted the wifi_loopback.grc from gr-ieee 802.11
> to my blank project and made it run. Off course I took care of the initial
> settings of the variables and all. It ran successfully. Then I copy pasted
> the transceiver_OQPSK.grc from gr-ieee 802.15.4 to the same grc project
> where wifi_loopback.grc was there. Then I separated the variables carefully
> and make both wifi_loopback and transceiver_OQPSK to run under the same flow
> graph at the same time. They ran successfully without any issue! 
> 
> In the next step, I tried to create an environment of interference between
> WiFi and ZigBee by adding the baseband output of WiFi transmitter and ZigBee
> transmitter. But before that I upsampled the ZigBee 5 times to make it 20
> MHz wide. 
> 
> In the next step, I took the output of mixed signal i.e. ZigBee + WiFi and
> fed it to individual receivers. Here also I downsampled the mixed signal to
> 4 MHz before feeding it to the ZigBee receiver. 
> 
> But this setup din't work at all. The grc just turned dark. There were no
> error messages. I am not sure where I am theoretically and/or practically
> wrong. 
> 
> * I am trying to analyse WiFi and ZigBee interference. 
> 
> Regards


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

[Discuss-gnuradio] Running gr-ieee 802.11 and gr-ieee 802.15.4 under same flowgraph (interference and co-existence)

[sumitstop]

Hello, 
(Its a long post :) as I want to give as much details as possible)

Today I did a strange experiment. Under GNU Radio companion, I created a
blank project. Then I copy pasted the wifi_loopback.grc from gr-ieee 802.11
to my blank project and made it run. Off course I took care of the initial
settings of the variables and all. It ran successfully. Then I copy pasted
the transceiver_OQPSK.grc from gr-ieee 802.15.4 to the same grc project
where wifi_loopback.grc was there. Then I separated the variables carefully
and make both wifi_loopback and transceiver_OQPSK to run under the same flow
graph at the same time. They ran successfully without any issue! 

In the next step, I tried to create an environment of interference between
WiFi and ZigBee by adding the baseband output of WiFi transmitter and ZigBee
transmitter. But before that I upsampled the ZigBee 5 times to make it 20
MHz wide. 

In the next step, I took the output of mixed signal i.e. ZigBee + WiFi and
fed it to individual receivers. Here also I downsampled the mixed signal to
4 MHz before feeding it to the ZigBee receiver. 

But this setup din't work at all. The grc just turned dark. There were no
error messages. I am not sure where I am theoretically and/or practically
wrong. 

* I am trying to analyse WiFi and ZigBee interference. 

Regards
Sumit 



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Running-gr-ieee-802-11-and-gr-ieee-802-15-4-under-same-flowgraph-interference-and-co-existence-tp64474.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

[Discuss-gnuradio] running bastibl's IEEE802.11 in the USRP E310

[Gabriel Pechiarovich]

Hi all, I just installed this module in my E310, to run the loopback in the
E310 i modified the flow graph so it is no gui, but when i'm running in the
E310 i got a segmentation fault and the program stops:

root@ettus-e300:~/wifi-master# python wifi_loopback_ngui.py
linux; GNU C++ version 4.9.1; Boost_105600; UHD_003.008.005-0-unknown

Using Volk machine: neon_hardfp
OFDM MAPPER: encoding: 0
set_min_output_buffer on block 10 to 96000
set_min_output_buffer on block 12 to 96000
set_min_output_buffer on block 14 to 96000
set_min_output_buffer on block 15 to 96000
Segmentation fault
root@ettus-e300:~/wifi-master#

I need to run at least the loopback
thank you in andvance


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

[Discuss-gnuradio] running error

[kerry]

Hi,all:

I try to run an example about gnu radio. The runtime errors are captured as:

Using Volk machine: sse4_1_64_orc
gr-osmosdr v0.1.4-48-g86ad5842 (0.1.5git) gnuradio 3.7.7.2
built-in source types: file fcd rtl rtl_tcp uhd bladerf rfspace 
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes

FATAL: RuntimeError: 
Please update the firmware and FPGA images for your device.
See the application notes for USRP2/N-Series for instructions.
Expected FPGA compatibility number 11, but got 10:
The FPGA build is not compatible with the host code build.
Could not find usrp_n210_fw.bin and usrp_n210_r4_fpga.bin in your images
path!
Please run:

 "/usr/local/lib/uhd/utils/uhd_images_downloader.py"


Trying to fill up 1 missing channel(s) with null source(s).
This is being done to prevent the application from crashing
due to gnuradio bug #528.


>>> Done

Generating: "/usr/local/share/gnuradio/examples/audio/hello_world.py"

Executing: "/usr/local/share/gnuradio/examples/audio/hello_world.py"

linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.009.000-1-g71985969

Using Volk machine: sse4_1_64_orc
gr-osmosdr v0.1.4-48-g86ad5842 (0.1.5git) gnuradio 3.7.7.2
built-in source types: file fcd rtl rtl_tcp uhd bladerf rfspace 

FATAL: No supported devices found to pick from.

Trying to fill up 1 missing channel(s) with null source(s).
This is being done to prevent the application from crashing
due to gnuradio bug #528.


>>> Done

Generating: "/usr/local/share/gnuradio/examples/audio/hello_world.py"

Generating: "/usr/local/share/gnuradio/examples/audio/hello_world.py"

Executing: "/usr/local/share/gnuradio/examples/audio/hello_world.py"

linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.009.000-1-g71985969

Using Volk machine: sse4_1_64_orc
gr-osmosdr v0.1.4-48-g86ad5842 (0.1.5git) gnuradio 3.7.7.2
built-in source types: file fcd rtl rtl_tcp uhd bladerf rfspace 
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes

FATAL: RuntimeError: 
Please update the firmware and FPGA images for your device.
See the application notes for USRP2/N-Series for instructions.
Expected FPGA compatibility number 11, but got 10:
The FPGA build is not compatible with the host code build.
Could not find usrp_n210_fw.bin and usrp_n210_r4_fpga.bin in your images
path!
Please run:

 "/usr/local/lib/uhd/utils/uhd_images_downloader.py"


Trying to fill up 1 missing channel(s) with null source(s).
This is being done to prevent the application from crashing
due to gnuradio bug #528.


>>> Done



But when I run: "/usr/local/lib/uhd/utils/uhd_images_downloader.py".

It said that

Images destination:  /usr/local/share/uhd/images
Downloading images from:
http://files.ettus.com/binaries/images/uhd-images_003.009.git-rc1.zip
Downloading images to:   /tmp/tmpqVXGpZ/uhd-images_003.009.git-rc1.zip
Downloader raised an unhandled exception: request() got an unexpected
keyword argument 'stream'
You can run this again with the '--verbose' flag to see more information
If the problem persists, please email the output to: supp...@ettus.com
-

Could anyone tell my why? Thx.

-Kerry



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/running-error-tp57136.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

Re: [Discuss-gnuradio] running error

[James Humphries]

Hi Kerry,

Did you hook your computer back up to the internet before you ran
uhd_images_downloader.py?

-Trip

On Mon, Nov 30, 2015 at 3:22 PM, kerry  wrote:

> Hi,all:
>
> I try to run an example about gnu radio. The runtime errors are captured
> as:
>
> Using Volk machine: sse4_1_64_orc
> gr-osmosdr v0.1.4-48-g86ad5842 (0.1.5git) gnuradio 3.7.7.2
> built-in source types: file fcd rtl rtl_tcp uhd bladerf rfspace
> -- Opening a USRP2/N-Series device...
> -- Current recv frame size: 1472 bytes
> -- Current send frame size: 1472 bytes
>
> FATAL: RuntimeError:
> Please update the firmware and FPGA images for your device.
> See the application notes for USRP2/N-Series for instructions.
> Expected FPGA compatibility number 11, but got 10:
> The FPGA build is not compatible with the host code build.
> Could not find usrp_n210_fw.bin and usrp_n210_r4_fpga.bin in your images
> path!
> Please run:
>
>  "/usr/local/lib/uhd/utils/uhd_images_downloader.py"
>
>
> Trying to fill up 1 missing channel(s) with null source(s).
> This is being done to prevent the application from crashing
> due to gnuradio bug #528.
>
>
> >>> Done
>
> Generating: "/usr/local/share/gnuradio/examples/audio/hello_world.py"
>
> Executing: "/usr/local/share/gnuradio/examples/audio/hello_world.py"
>
> linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.009.000-1-g71985969
>
> Using Volk machine: sse4_1_64_orc
> gr-osmosdr v0.1.4-48-g86ad5842 (0.1.5git) gnuradio 3.7.7.2
> built-in source types: file fcd rtl rtl_tcp uhd bladerf rfspace
>
> FATAL: No supported devices found to pick from.
>
> Trying to fill up 1 missing channel(s) with null source(s).
> This is being done to prevent the application from crashing
> due to gnuradio bug #528.
>
>
> >>> Done
>
> Generating: "/usr/local/share/gnuradio/examples/audio/hello_world.py"
>
> Generating: "/usr/local/share/gnuradio/examples/audio/hello_world.py"
>
> Executing: "/usr/local/share/gnuradio/examples/audio/hello_world.py"
>
> linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.009.000-1-g71985969
>
> Using Volk machine: sse4_1_64_orc
> gr-osmosdr v0.1.4-48-g86ad5842 (0.1.5git) gnuradio 3.7.7.2
> built-in source types: file fcd rtl rtl_tcp uhd bladerf rfspace
> -- Opening a USRP2/N-Series device...
> -- Current recv frame size: 1472 bytes
> -- Current send frame size: 1472 bytes
>
> FATAL: RuntimeError:
> Please update the firmware and FPGA images for your device.
> See the application notes for USRP2/N-Series for instructions.
> Expected FPGA compatibility number 11, but got 10:
> The FPGA build is not compatible with the host code build.
> Could not find usrp_n210_fw.bin and usrp_n210_r4_fpga.bin in your images
> path!
> Please run:
>
>  "/usr/local/lib/uhd/utils/uhd_images_downloader.py"
>
>
> Trying to fill up 1 missing channel(s) with null source(s).
> This is being done to prevent the application from crashing
> due to gnuradio bug #528.
>
>
> >>> Done
>
> 
>
> But when I run: "/usr/local/lib/uhd/utils/uhd_images_downloader.py".
>
> It said that
>
> Images destination:  /usr/local/share/uhd/images
> Downloading images from:
> http://files.ettus.com/binaries/images/uhd-images_003.009.git-rc1.zip
> Downloading images to:   /tmp/tmpqVXGpZ/uhd-images_003.009.git-rc1.zip
> Downloader raised an unhandled exception: request() got an unexpected
> keyword argument 'stream'
> You can run this again with the '--verbose' flag to see more information
> If the problem persists, please email the output to: supp...@ettus.com
> -
>
> Could anyone tell my why? Thx.
>
> -Kerry
>
>
>
> --
> View this message in context:
> http://gnuradio.4.n7.nabble.com/running-error-tp57136.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
> ___
> 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] running error

[Neel Pandeya]

Hello Kerry:

Perhaps your computer is behind a firewall or proxy server?? Many companies
and universities use them, and they often block these type of downloads.

--Neel



On 30 November 2015 at 13:41, James Humphries 
wrote:

> Hi Kerry,
>
> Did you hook your computer back up to the internet before you ran
> uhd_images_downloader.py?
>
> -Trip
>
> On Mon, Nov 30, 2015 at 3:22 PM, kerry  wrote:
>
>> Hi,all:
>>
>> I try to run an example about gnu radio. The runtime errors are captured
>> as:
>>
>> Using Volk machine: sse4_1_64_orc
>> gr-osmosdr v0.1.4-48-g86ad5842 (0.1.5git) gnuradio 3.7.7.2
>> built-in source types: file fcd rtl rtl_tcp uhd bladerf rfspace
>> -- Opening a USRP2/N-Series device...
>> -- Current recv frame size: 1472 bytes
>> -- Current send frame size: 1472 bytes
>>
>> FATAL: RuntimeError:
>> Please update the firmware and FPGA images for your device.
>> See the application notes for USRP2/N-Series for instructions.
>> Expected FPGA compatibility number 11, but got 10:
>> The FPGA build is not compatible with the host code build.
>> Could not find usrp_n210_fw.bin and usrp_n210_r4_fpga.bin in your images
>> path!
>> Please run:
>>
>>  "/usr/local/lib/uhd/utils/uhd_images_downloader.py"
>>
>>
>> Trying to fill up 1 missing channel(s) with null source(s).
>> This is being done to prevent the application from crashing
>> due to gnuradio bug #528.
>>
>>
>> >>> Done
>>
>> Generating: "/usr/local/share/gnuradio/examples/audio/hello_world.py"
>>
>> Executing: "/usr/local/share/gnuradio/examples/audio/hello_world.py"
>>
>> linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.009.000-1-g71985969
>>
>> Using Volk machine: sse4_1_64_orc
>> gr-osmosdr v0.1.4-48-g86ad5842 (0.1.5git) gnuradio 3.7.7.2
>> built-in source types: file fcd rtl rtl_tcp uhd bladerf rfspace
>>
>> FATAL: No supported devices found to pick from.
>>
>> Trying to fill up 1 missing channel(s) with null source(s).
>> This is being done to prevent the application from crashing
>> due to gnuradio bug #528.
>>
>>
>> >>> Done
>>
>> Generating: "/usr/local/share/gnuradio/examples/audio/hello_world.py"
>>
>> Generating: "/usr/local/share/gnuradio/examples/audio/hello_world.py"
>>
>> Executing: "/usr/local/share/gnuradio/examples/audio/hello_world.py"
>>
>> linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.009.000-1-g71985969
>>
>> Using Volk machine: sse4_1_64_orc
>> gr-osmosdr v0.1.4-48-g86ad5842 (0.1.5git) gnuradio 3.7.7.2
>> built-in source types: file fcd rtl rtl_tcp uhd bladerf rfspace
>> -- Opening a USRP2/N-Series device...
>> -- Current recv frame size: 1472 bytes
>> -- Current send frame size: 1472 bytes
>>
>> FATAL: RuntimeError:
>> Please update the firmware and FPGA images for your device.
>> See the application notes for USRP2/N-Series for instructions.
>> Expected FPGA compatibility number 11, but got 10:
>> The FPGA build is not compatible with the host code build.
>> Could not find usrp_n210_fw.bin and usrp_n210_r4_fpga.bin in your images
>> path!
>> Please run:
>>
>>  "/usr/local/lib/uhd/utils/uhd_images_downloader.py"
>>
>>
>> Trying to fill up 1 missing channel(s) with null source(s).
>> This is being done to prevent the application from crashing
>> due to gnuradio bug #528.
>>
>>
>> >>> Done
>>
>> 
>>
>> But when I run: "/usr/local/lib/uhd/utils/uhd_images_downloader.py".
>>
>> It said that
>>
>> Images destination:  /usr/local/share/uhd/images
>> Downloading images from:
>> http://files.ettus.com/binaries/images/uhd-images_003.009.git-rc1.zip
>> Downloading images to:   /tmp/tmpqVXGpZ/uhd-images_003.009.git-rc1.zip
>> Downloader raised an unhandled exception: request() got an unexpected
>> keyword argument 'stream'
>> You can run this again with the '--verbose' flag to see more information
>> If the problem persists, please email the output to: supp...@ettus.com
>> -
>>
>> Could anyone tell my why? Thx.
>>
>> -Kerry
>>
>>
>>
>> --
>> View this message in context:
>> http://gnuradio.4.n7.nabble.com/running-error-tp57136.html
>> Sent from the GnuRadio mailing list archive at Nabble.com.
>>
>> ___
>> 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] running error

[Marcus D. Leech]

On 11/30/2015 08:39 PM, Neel Pandeya wrote:

Hello Kerry:

Perhaps your computer is behind a firewall or proxy server?? Many 
companies and universities use them, and they often block these type 
of downloads.


--Neel

Actually, looking at the message, it looks like an incompatibility 
between whatever version of "python-requests" is on the computer, and
  what uhd_images_downloader.py is expecting see the "unexpected 
keyword argument" error below.






On 30 November 2015 at 13:41, James Humphries 
> wrote:


Hi Kerry,

Did you hook your computer back up to the internet before you ran
uhd_images_downloader.py?

-Trip

On Mon, Nov 30, 2015 at 3:22 PM, kerry > wrote:

Hi,all:

I try to run an example about gnu radio. The runtime errors
are captured as:

Using Volk machine: sse4_1_64_orc
gr-osmosdr v0.1.4-48-g86ad5842 (0.1.5git) gnuradio 3.7.7.2
built-in source types: file fcd rtl rtl_tcp uhd bladerf rfspace
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes

FATAL: RuntimeError:
Please update the firmware and FPGA images for your device.
See the application notes for USRP2/N-Series for instructions.
Expected FPGA compatibility number 11, but got 10:
The FPGA build is not compatible with the host code build.
Could not find usrp_n210_fw.bin and usrp_n210_r4_fpga.bin in
your images
path!
Please run:

 "/usr/local/lib/uhd/utils/uhd_images_downloader.py"


Trying to fill up 1 missing channel(s) with null source(s).
This is being done to prevent the application from crashing
due to gnuradio bug #528.


>>> Done

Generating:
"/usr/local/share/gnuradio/examples/audio/hello_world.py"

Executing:
"/usr/local/share/gnuradio/examples/audio/hello_world.py"

linux; GNU C++ version 4.6.3; Boost_104800;
UHD_003.009.000-1-g71985969

Using Volk machine: sse4_1_64_orc
gr-osmosdr v0.1.4-48-g86ad5842 (0.1.5git) gnuradio 3.7.7.2
built-in source types: file fcd rtl rtl_tcp uhd bladerf rfspace

FATAL: No supported devices found to pick from.

Trying to fill up 1 missing channel(s) with null source(s).
This is being done to prevent the application from crashing
due to gnuradio bug #528.


>>> Done

Generating:
"/usr/local/share/gnuradio/examples/audio/hello_world.py"

Generating:
"/usr/local/share/gnuradio/examples/audio/hello_world.py"

Executing:
"/usr/local/share/gnuradio/examples/audio/hello_world.py"

linux; GNU C++ version 4.6.3; Boost_104800;
UHD_003.009.000-1-g71985969

Using Volk machine: sse4_1_64_orc
gr-osmosdr v0.1.4-48-g86ad5842 (0.1.5git) gnuradio 3.7.7.2
built-in source types: file fcd rtl rtl_tcp uhd bladerf rfspace
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes

FATAL: RuntimeError:
Please update the firmware and FPGA images for your device.
See the application notes for USRP2/N-Series for instructions.
Expected FPGA compatibility number 11, but got 10:
The FPGA build is not compatible with the host code build.
Could not find usrp_n210_fw.bin and usrp_n210_r4_fpga.bin in
your images
path!
Please run:

 "/usr/local/lib/uhd/utils/uhd_images_downloader.py"


Trying to fill up 1 missing channel(s) with null source(s).
This is being done to prevent the application from crashing
due to gnuradio bug #528.


>>> Done



But when I run:
"/usr/local/lib/uhd/utils/uhd_images_downloader.py".

It said that

Images destination:  /usr/local/share/uhd/images
Downloading images from:
http://files.ettus.com/binaries/images/uhd-images_003.009.git-rc1.zip
Downloading images to:
 /tmp/tmpqVXGpZ/uhd-images_003.009.git-rc1.zip
Downloader raised an unhandled exception: request() got an
unexpected
keyword argument 'stream'
You can run this again with the '--verbose' flag to see more
information
If the problem persists, please email the output to:
supp...@ettus.com 

-

Could anyone tell my why? Thx.

-Kerry



--
View this message in context:
http://gnuradio.4.n7.nabble.com/running-error-tp57136.html
Sent from 

Re: [Discuss-gnuradio] Running flowgraphs from command line

[Patrick Krämer]

Hey Michael, Hey Kevin, Hey all,

thanks for your help!
I found that by specifying the python version I want to use when running the 
file, everything works fine. Like this:

python2.7 if_else_mod.py 

This would be acceptable for me, however, I decided to do some of the stuff you 
suggested. I get the following output when running env:

Patricks-iMac:~ patrick$ env
TERM_PROGRAM=Apple_Terminal
SHELL=/bin/bash
TERM=xterm-256color
TMPDIR=/var/folders/3j/qy7_9bpx29g_nf_ymbkw_td0gn/T/
Apple_PubSub_Socket_Render=/private/tmp/com.apple.launchd.11PeMdZFpD/Render
TERM_PROGRAM_VERSION=343.7
TERM_SESSION_ID=1FC9A988-7B1E-4869-95D3-5FF71F9942F7
USER=patrick
SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.0PyXsYlSwi/Listeners
__CF_USER_TEXT_ENCODING=0x1F5:0x0:0x3
PATH=/opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin
PWD=/Users/patrick
DBUS_LAUNCHD_SESSION_BUS_SOCKET=/private/tmp/com.apple.launchd.dJkzL2MOo1/unix_domain_listener
LANG=de_DE.UTF-8
XPC_FLAGS=0x0
XPC_SERVICE_NAME=0
SHLVL=1
HOME=/Users/patrick
LOGNAME=patrick
DISPLAY=/private/tmp/com.apple.launchd.KWH6aSklFz/org.macosforge.xquartz:0
_=/usr/bin/env


I see that I only have a PATH variable set, but no PYTHONPATH. And 
/opt/local/bin seems to be the first in place?! With

Patricks-iMac:bin patrick$ pwd
/usr/bin
Patricks-iMac:bin patrick$ ./py
pydoc pythonpython2.6-config  pythonw
pydoc2.6  python-config python2.7 pythonw2.6
pydoc2.7  python2.6 python2.7-config  pythonw2.7

I see that I have even more python installs. Now I ran

Patricks-iMac:bin patrick$ which python
/usr/bin/python
Patricks-iMac:bin patrick$ port select --list python
Available versions for python:
none (active)
python26-apple
python27
python27-apple

So terminal normally would run "python" (didn’t look up the version). And 
MacPorts?
All this is what comes out of a clean OS X 10.9 install with an update to 10.10 
and then a GNURadio install via MacPorts. Didn’t try yet to change one of the 
env variables or use the 'sudo port select python python27‘ command. What would 
your suggestions now be? What I don’t understand is why I have to tell MacPorts 
to use python2.7, if in fact I want to tell that to my terminal?

Thanks & Regards
Patrick



> Am 08.09.2015 um 03:04 schrieb Michael Dickens :
> 
> Hi Patrick - So what's happening is that with GRC, because it was
> installed via MacPorts the MP version of Python is used. The terminal
> only knows what you tell it via environment variables such as PYTHONPATH
> (already suggested by Kevin Hofschröer) and PATH. In your case right
> now, I'll bet that the PATH contains /usr/bin before /opt/local/bin (if
> the latter is listed at all). If you do "which python", you'll see what
> your shell is executing when you type "python" (again, better
> /usr/bin/python [2.7 something]). Even if you add /opt/local/bin at the
> start of PATH, you might still need to tell MP to select the version of
> Python you want to use when you type "python" in the shell. You can list
> the options port has via "port select --list python", and then select
> Python 2.7 via "sudo port select python python27" if it not already
> active. Combining this with making sure /opt/local/bin comes first in
> PATH should solve your issue. Hope this helps! - MLD
> 
> On Mon, Sep 7, 2015, at 12:29 PM, Patrick Krämer wrote:
>> I installed GNURadio on a fresh machine with Mac OS X 10.10.5 via
>> MacPorts. I now have 2 Python installs in /usr/bin, python2.6 and
>> python2.7. Running flowgraphs with GRC is no problem. However, when
>> trying to run a .py-file from the terminal, as suggested in the guided
>> tutorial 3.1 („if else“) some modules are not found:
>> 
>> Patricks-iMac:work patrick$ python if_else_mod.py Traceback (most
>> recent call last):  File "if_else_mod.py", line 18, in 
>> from PyQt4 import Qt ImportError: No module named PyQt4
>> 
>> 
>> Why does it work, when running the file from GRC? Is my terminal using
>> the wrong python install? How could I change that? I also tried
>> changing the path variable on my notebook a few days ago, when I ran
>> into the same problem. But since I am new to python and the command
>> line I obviously made a mistake so that at some point I could not
>> start the GRC anymore. So your help is appreciated and needed.
>> Couldn’t find a similar question in the archives.
> 
> ___
> 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] Running flowgraphs from command line

[Michael Dickens]

Hi Patrick - You're on the right track. We're just following what is written 
(roughly) in < http://gnuradio.org/redmine/projects/gnuradio/wiki/MacInstall >. 
Please also note that unless you play some tricks with the +quartz variant that 
is available many GR dependencies, you'll have to install XQuartz.app to get 
any GUI working (see also 
http://gnuradio.org/redmine/projects/gnuradio/wiki/MacInstall#Prerequisite-X11app-recommended-via-XQuartz
 ). Your shell env looks good; because MP's Python internally set their 
PYTHONPATH, you won't need to so long as you use MP-provided GR projects (e.g., 
gr-fosphor). If you want to do your own out-of-tree builds, you can install 
them pretty much anywhere so long as the libraries are linked correctly and 
PYTHONPATH is set correctly to wherever your OOT Python module is installed. 

You ask a variety of questions about Python usage in OSX. Apple provides
Python 2.6 and 2.7 in /usr/bin in most modern OSX versions; in MP, you
can get Python 2.7, 3.4, and 3.5rc3. MP does not provide the other
Python versions because there really is no use case for them any longer
: 2.7 supersedes 2.6, just as 3.4 does with 3.[0-3]; 3.5 when it is
released should supersede 3.4, so we'll likely push end users to

As to your question as to which 'python' is selected for use and when:
The times it matters is when 'python' is issued either in a shell or in
a script via "env python". In this case, the first 'python' found in the
shell PATH is used. Thus, issuing "sudo port select python python27"
means that, more often than not, 'python' will result in the MP version
(2.7) being executed. Which in general is OK. When you need to use the
OSX system one you can always do that by either removing /opt/local/bin
from PATH or by specifying "env /usr/bin/python"; there are other ways
too. But, as a general use-case having "which python" result in
/opt/local/bin/python is not a bad idea.

-That said-, you should never rely on a specific "python" being the one
you expect it to be. If you want a specific Python, you'll red to test
for it or just specify it up front, e.g., "/opt/local/bin/python2.7".

Hope this continues to help! - MLD

On Tue, Sep 8, 2015, at 03:34 AM, Patrick Krämer wrote:
> Hey Michael, Hey Kevin, Hey all,
>
> thanks for your help! I found that by specifying the python version I
> want to use when running the file, everything works fine. Like this:
>
> python2.7 if_else_mod.py
>
> This would be acceptable for me, however, I decided to do some of the
> stuff you suggested. I get the following output when running env:
>
> Patricks-iMac:~ patrick$ env TERM_PROGRAM=Apple_Terminal
> SHELL=/bin/bash TERM=xterm-256color
> TMPDIR=/var/folders/3j/qy7_9bpx29g_nf_ymbkw_td0gn/T/ Apple_PubSub-
> _Socket_Render=/private/tmp/com.apple.launchd.11PeMdZFpD/Render
> TERM_PROGRAM_VERSION=343.7 TERM_SESSION_ID=1FC9A988-7B1E-4869-95D3-
> 5FF71F9942F7 USER=patrick
> SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.0PyXsYlSwi/Listeners
> __CF_USER_TEXT_ENCODING=0x1F5:0x0:0x3 PATH=/opt/local/bin:/opt/local/-
> sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin
> PWD=/Users/patrick DBUS_LAUNCHD_SESSION_BUS_SOCKET=/private/tmp/com.a-
> pple.launchd.dJkzL2MOo1/unix_domain_listener LANG=de_DE.UTF-8
> XPC_FLAGS=0x0 XPC_SERVICE_NAME=0 SHLVL=1 HOME=/Users/patrick
> LOGNAME=patrick DISPLAY=/private/tmp/com.apple.launchd.KWH6aSklFz/org-
> .macosforge.xquartz:0 _=/usr/bin/env
>
>
> I see that I only have a PATH variable set, but no PYTHONPATH. And
> /opt/local/bin seems to be the first in place?! With
>
> Patricks-iMac:bin patrick$ pwd /usr/bin Patricks-iMac:bin patrick$
> ./py pydoc             python            python2.6-config  pythonw
> pydoc2.6          python-config     python2.7         pythonw2.6
> pydoc2.7          python2.6         python2.7-config  pythonw2.7
>
> I see that I have even more python installs. Now I ran
>
> Patricks-iMac:bin patrick$ which python /usr/bin/python Patricks-
> iMac:bin patrick$ port select --list python Available versions for
> python: none (active) python26-apple python27 python27-apple
>
> So terminal normally would run "python" (didn’t look up the version).
> And MacPorts? All this is what comes out of a clean OS X 10.9 install
> with an update to 10.10 and then a GNURadio install via MacPorts.
> Didn’t try yet to change one of the env variables or use the 'sudo
> port select python python27‘ command. What would your suggestions now
> be? What I don’t understand is why I have to tell MacPorts to use
> python2.7, if in fact I want to tell that to my terminal?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Running flowgraphs from command line

[Patrick Krämer]

Hi,

I did the following command, as suggested: 

Patricks-iMac:work patrick$ sudo port select python python27
Selecting 'python27' for 'python' succeeded. 'python27' is now active.
Patricks-iMac:work patrick$ python if_else_mod.py 
Fatal Python error: PyThreadState_Get: no current thread
Abort trap: 6


As you can see python crashes and I also get another GUI fail message. Running 
like python2.7 if_else_mod.py still works, though. I tried to revert the above 
change, but:

Patricks-iMac:work patrick$ sudo port select python python
Selecting 'python' for 'python' failed: The specified version 'python' is not 
valid.

Think I will just stick with the way that works, until I at some point need to 
change something and then dive more into this. Thanks for your patience though.

Greetings
Patrick

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

[Discuss-gnuradio] Running flowgraphs from command line

[Patrick Krämer]

Hi everybody,

I installed GNURadio on a fresh machine with Mac OS X 10.10.5 via MacPorts. I 
now have 2 Python installs in /usr/bin, python2.6 and python2.7. Running 
flowgraphs with GRC is no problem. However, when trying to run a .py-file from 
the terminal, as suggested in the guided tutorial 3.1 („if else“) some modules 
are not found: 

Patricks-iMac:work patrick$ python if_else_mod.py
Traceback (most recent call last):
  File "if_else_mod.py", line 18, in 
from PyQt4 import Qt
ImportError: No module named PyQt4


Why does it work, when running the file from GRC? Is my terminal using the 
wrong python install? How could I change that? I also tried changing the path 
variable on my notebook a few days ago, when I ran into the same problem. But 
since I am new to python and the command line I obviously made a mistake so 
that at some point I could not start the GRC anymore. So your help is 
appreciated and needed. Couldn’t find a similar question in the archives.

Thank you.
Patrick


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

Re: [Discuss-gnuradio] Running flowgraphs from command line

[Kevin Hofschröer]

Hi Patrick,

I think I might have the answer, although Michael Dickens could
certainly provide better explanations and all that.

You need to check your environment variables. You can do that in the
command line by typing "env".
Normally you should see something like
"
PYTHONPATH=/opt/local/Library/Frameworks/Python.framework/Version/2.7/lib/python2.7/site-packages/:/opt/local/lib/:/usr/local/lib/
"
in the output.
Normally Macports should adapt your ~/.profile file in order to tell
your system where Macports put the stuff you installed.

If for some reasons that fails, your PYTHONPATH (in this case) will not
point to the correct directories.

If that indeed is the case, then you might insert some lines to your
~/.profile file, i.e.

"export
PYTHONPATH=/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/:/opt/local/lib/:/usr/local/lib/:$PYTHONPATH"

and

"export PATH="/opt/local/bin:/opt/local/sbin:$PATH""

at the end of that file.

You might want to make sure that you can find PyQT4 yourself in those
given directories. For example my PyQT4 folder is under

"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages"

After you inserted those lines to your .profile, you just need to open a
new terminal, and you can again check via "env" if that worked out.

Regards,
Kevin


Am 07.09.15 um 18:29 schrieb Patrick Krämer:
> Hi everybody,
> 
> I installed GNURadio on a fresh machine with Mac OS X 10.10.5 via MacPorts. I 
> now have 2 Python installs in /usr/bin, python2.6 and python2.7. Running 
> flowgraphs with GRC is no problem. However, when trying to run a .py-file 
> from the terminal, as suggested in the guided tutorial 3.1 („if else“) some 
> modules are not found: 
> 
> Patricks-iMac:work patrick$ python if_else_mod.py
> Traceback (most recent call last):
>   File "if_else_mod.py", line 18, in 
> from PyQt4 import Qt
> ImportError: No module named PyQt4
> 
> 
> Why does it work, when running the file from GRC? Is my terminal using the 
> wrong python install? How could I change that? I also tried changing the path 
> variable on my notebook a few days ago, when I ran into the same problem. But 
> since I am new to python and the command line I obviously made a mistake so 
> that at some point I could not start the GRC anymore. So your help is 
> appreciated and needed. Couldn’t find a similar question in the archives.
> 
> Thank you.
> Patrick
> 
> 
> 
> 
> 
> ___
> 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] Running flowgraphs from command line

[Michael Dickens]

Hi Patrick - So what's happening is that with GRC, because it was
installed via MacPorts the MP version of Python is used. The terminal
only knows what you tell it via environment variables such as PYTHONPATH
(already suggested by Kevin Hofschröer) and PATH. In your case right
now, I'll bet that the PATH contains /usr/bin before /opt/local/bin (if
the latter is listed at all). If you do "which python", you'll see what
your shell is executing when you type "python" (again, better
/usr/bin/python [2.7 something]). Even if you add /opt/local/bin at the
start of PATH, you might still need to tell MP to select the version of
Python you want to use when you type "python" in the shell. You can list
the options port has via "port select --list python", and then select
Python 2.7 via "sudo port select python python27" if it not already
active. Combining this with making sure /opt/local/bin comes first in
PATH should solve your issue. Hope this helps! - MLD

On Mon, Sep 7, 2015, at 12:29 PM, Patrick Krämer wrote:
> I installed GNURadio on a fresh machine with Mac OS X 10.10.5 via
> MacPorts. I now have 2 Python installs in /usr/bin, python2.6 and
> python2.7. Running flowgraphs with GRC is no problem. However, when
> trying to run a .py-file from the terminal, as suggested in the guided
> tutorial 3.1 („if else“) some modules are not found:
>
> Patricks-iMac:work patrick$ python if_else_mod.py Traceback (most
> recent call last):  File "if_else_mod.py", line 18, in 
> from PyQt4 import Qt ImportError: No module named PyQt4
>
>
> Why does it work, when running the file from GRC? Is my terminal using
> the wrong python install? How could I change that? I also tried
> changing the path variable on my notebook a few days ago, when I ran
> into the same problem. But since I am new to python and the command
> line I obviously made a mistake so that at some point I could not
> start the GRC anymore. So your help is appreciated and needed.
> Couldn’t find a similar question in the archives.

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

Re: [Discuss-gnuradio] Running a GNU Radio Companion generated code

[Daniel Camara]

Hi Johannes,

 THANKS a lot  Yes you did really helped, as you said I was trying to
run the wrong .py!!!  The example generates two .py on on the main
directory, as you said, and another on the ~/.grc_gnuradio. I had seen
somewhere that gnuradio companion generate code on the  ~/.grc_gnuradio.  I
looked, the code was there, I didn't even think it could have also
generated other part of the code on the same directory of the .grc.  It was
naive, sorry.

 I managed to run and connect gdb to it, using the PID.  Now things will
become really interesting, i.e.e me fighting with gdb, and the breakpoints,
to understand the values it passes through the code ;).

 Thanks again Johannes, for taking your time to answer! :)

   Best regards...

   Daniel

On Mon, Dec 22, 2014 at 4:24 PM, Johannes Demel uf...@student.kit.edu
wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hi Daniel,

  OK I have a code, generated with Gnu radio companion that i want
  to run over the command line to follow with GDB. I was under the
  impression that if I simply got the code generated in the
  ~/.grc_gnuradio, add the
 This folder usually only contains 'hier_blocks'. Executable flowgraph
 pythons files are usually created in the same folder your .grc file is
 located in.

 
  
 
  |def main():  go, go, go  top_block = [CLASS]()
  top_block.run()
 Did you replace a class by [Class]? According to the Tutorial it
 expects an object of type gr.top_block in this line.

 
  if __name__ == __main__: print 'Blocked waiting for GDB attach
  (pid = %d)' % (os.getpid(),) raw_input ('Press Enter to continue:
  ') main()  |
 
  as stated at
  https://gnuradio.org/redmine/projects/gnuradio/wiki/TutorialsDebugging
 
 
 it would run to attach GDB. However, i am getting the following error:
 
  --- Traceback (most recent call last): File ieee802_15_4_phy.py,
  line 120, in module main() File ieee802_15_4_phy.py, line 115,
  in main top_block.run() File
  /usr/local/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py,
 
 
 line 53, in __getattr__
  return getattr(self._hb, name) AttributeError: 'hier_block2_sptr'
  object has no attribute 'run'
 You try to call run on a 'hier_block'. 'run' is a member of
 'gr.top_block'. top_block contains the scheduler and takes care of
 correct initialization etc. So it is essentially the flowgraph.

 I hope I could give you some hints on what might go wrong.
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1

 iQIcBAEBAgAGBQJUmDfBAAoJEO7fmkDsqywMbyoQAKyANgElQ64/Ox81/gwl4TOY
 k3NCr9Stj8CEUG65bYBPo4eDoVT5+xyA7e4HYTYrKMlHT+J2c/iG3ckH9sK7khoO
 1jpFOtQn688tih6uBRhlVgNKWH26B2Hia8U4zIzavDcnt+B3aIRm+MG19Zlg6Ggg
 XLD9KeJ6A5nfgrx+jsylAZGWmp4u6ZFupAVjuTA0vHab/3BOjCuJq2IOveWtSfhg
 gPoHowIvWFwuiR/owJjwHhSGyCmZU1/Iz3yGT0TLdOZ8odlP0z9braIOt2bT3x9V
 OQzgpQFBVuEEdSRJETZkWw0Lr4Jwl/Bko9pHi3tj6MGEcq8U6fP4Ml8dhiG1IE9q
 UZ9XdSNJqDBNylfRxsyBm1oBmUV/gF6mXpD3851lQLdTNvP3R2QD7QrFP9UxRPKj
 c300eaCsRhucDT7ApQmqTguPeL8ds+z6eN8BZ41BtD9etBPjbJDjoV+hfk4z16jF
 gHEjVTAKti2OCiyya19xb67XJoufNz3Fjn09idG7YDAYRG7Qvn3XZCUpLAzO79pg
 axceRvfxgMqws21NgTEDiEndDxjEeJm0mh1jcNUwoM6vlRar/JbEwRxPSCuvfUdx
 GQac8LmkYJsROja1UgADE06fTEJZtLWUEQqBXhKlBlQz6sx1OA42XU8PPDm5c3SY
 AQfwe85pgdf1nQY19UEv
 =wYmS
 -END PGP SIGNATURE-

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



-- 
Best regards...

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

[Discuss-gnuradio] Running a GNU Radio Companion generated code

[Daniel Camara]

Hi people,

  Sorry for the dummy question, but I didn't find a simple and direct
answer searching around for this. (Not need to say also that I am just
starting with GNU Radio... :)

  OK I have a code, generated with Gnu radio companion that i want to run
over the command line to follow with GDB. I was under the impression that
if I simply got the code generated in the ~/.grc_gnuradio, add the



def main():
 go, go, go 
top_block = [CLASS]()
top_block.run()
if __name__ == __main__:
print 'Blocked waiting for GDB attach (pid = %d)' % (os.getpid(),)
raw_input ('Press Enter to continue: ')
main()


as stated at
https://gnuradio.org/redmine/projects/gnuradio/wiki/TutorialsDebugging it
would run to attach GDB. However, i am getting the following error:

---
Traceback (most recent call last):
  File ieee802_15_4_phy.py, line 120, in module
main()
  File ieee802_15_4_phy.py, line 115, in main
top_block.run()
  File /usr/local/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py,
line 53, in __getattr__
return getattr(self._hb, name)
AttributeError: 'hier_block2_sptr' object has no attribute 'run'
---

The code runs correctly on Gnuradio companion! No problem whatsoever!
Which would be the correct way to run the code auto-generated by gnuradio
companion in a stand alone way?

  Thanks in advance...

   Daniel


-- 
Best regards...

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

Re: [Discuss-gnuradio] Running a GNU Radio Companion generated code

[Johannes Demel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Daniel,

 OK I have a code, generated with Gnu radio companion that i want
 to run over the command line to follow with GDB. I was under the
 impression that if I simply got the code generated in the
 ~/.grc_gnuradio, add the
This folder usually only contains 'hier_blocks'. Executable flowgraph
pythons files are usually created in the same folder your .grc file is
located in.

 
 
 
 |def main():  go, go, go  top_block = [CLASS]() 
 top_block.run()
Did you replace a class by [Class]? According to the Tutorial it
expects an object of type gr.top_block in this line.

 
 if __name__ == __main__: print 'Blocked waiting for GDB attach
 (pid = %d)' % (os.getpid(),) raw_input ('Press Enter to continue:
 ') main()  |
 
 as stated at 
 https://gnuradio.org/redmine/projects/gnuradio/wiki/TutorialsDebugging

 
it would run to attach GDB. However, i am getting the following error:
 
 --- Traceback (most recent call last): File ieee802_15_4_phy.py,
 line 120, in module main() File ieee802_15_4_phy.py, line 115,
 in main top_block.run() File 
 /usr/local/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py,

 
line 53, in __getattr__
 return getattr(self._hb, name) AttributeError: 'hier_block2_sptr'
 object has no attribute 'run'
You try to call run on a 'hier_block'. 'run' is a member of
'gr.top_block'. top_block contains the scheduler and takes care of
correct initialization etc. So it is essentially the flowgraph.

I hope I could give you some hints on what might go wrong.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJUmDfBAAoJEO7fmkDsqywMbyoQAKyANgElQ64/Ox81/gwl4TOY
k3NCr9Stj8CEUG65bYBPo4eDoVT5+xyA7e4HYTYrKMlHT+J2c/iG3ckH9sK7khoO
1jpFOtQn688tih6uBRhlVgNKWH26B2Hia8U4zIzavDcnt+B3aIRm+MG19Zlg6Ggg
XLD9KeJ6A5nfgrx+jsylAZGWmp4u6ZFupAVjuTA0vHab/3BOjCuJq2IOveWtSfhg
gPoHowIvWFwuiR/owJjwHhSGyCmZU1/Iz3yGT0TLdOZ8odlP0z9braIOt2bT3x9V
OQzgpQFBVuEEdSRJETZkWw0Lr4Jwl/Bko9pHi3tj6MGEcq8U6fP4Ml8dhiG1IE9q
UZ9XdSNJqDBNylfRxsyBm1oBmUV/gF6mXpD3851lQLdTNvP3R2QD7QrFP9UxRPKj
c300eaCsRhucDT7ApQmqTguPeL8ds+z6eN8BZ41BtD9etBPjbJDjoV+hfk4z16jF
gHEjVTAKti2OCiyya19xb67XJoufNz3Fjn09idG7YDAYRG7Qvn3XZCUpLAzO79pg
axceRvfxgMqws21NgTEDiEndDxjEeJm0mh1jcNUwoM6vlRar/JbEwRxPSCuvfUdx
GQac8LmkYJsROja1UgADE06fTEJZtLWUEQqBXhKlBlQz6sx1OA42XU8PPDm5c3SY
AQfwe85pgdf1nQY19UEv
=wYmS
-END PGP SIGNATURE-

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

[Discuss-gnuradio] Running out of memory during BER simulations

[Felix W.]

Hi list,

I'm currently performing BER measurements for an IEEE 802.15.4 system. In
order to do so, I have created a flowgraph (in GRC/python) that is executed
for different SNR values until a certain number of bits has been processed.
Between every run, I call tb.stop() followed by tb.wait(). Unfortunately,
after a few runs (around 20), I get the following error message:

gr::vmcircbuf_sysv_shm: shmget (2): No space left on device
gr::vmcircbuf_sysv_shm: shmget (2): No space left on device
gr::vmcircbuf_sysv_shm: shmget (2): No space left on device
gr::buffer::allocate_buffer: failed to allocate buffer of size 64 KB
gr::vmcircbuf_sysv_shm: shmget (2): No space left on device
gr::vmcircbuf_sysv_shm: shmget (2): No space left on device
gr::vmcircbuf_sysv_shm: shmget (2): No space left on device
gr::buffer::allocate_buffer: failed to allocate buffer of size 64 KB
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
Aborted (core dumped)

sysctl says:
kernel.shmall = 2097152
kernel.shmmax = 2147483648

I don't really understand why this happens as my memory usage is very
stable and  20% of total RAM throughout the simulation. In my
understanding, calling, tb.stop() and tb.wait() should delete anything the
flowgraph allocated before. I also noticed that the block numbers (which
are displayed because I call set_min_output_buffer() ) are monotonically
increasing during the simulation even though the top block is stopped
multiple times. This might be completely unrelated, however it indicates
that my understanding might not be correct.

Any ideas?

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

Re: [Discuss-gnuradio] Running out of memory during BER simulations

[Marcus Müller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Felix,


On 11/25/2014 06:15 PM, Felix W. wrote:
 Between every run, I call tb.stop() followed by tb.wait().
 Unfortunately, after a few runs (around 20), I get the following
 error message:
 
 gr::vmcircbuf_sysv_shm: shmget (2): No space left on device
I have a suspicion.
First of all, I know this sounds basic, but you're not using a 32bit
GR on your 64 bit machine, are you? (that would explain running out of
RAM faster, just because process memory is so very limited for 32bit
processes)

then: vmcircbuf is one of the things I always was kind of hesitant to
touch (or even try to understand in depth), just because it deals with
a lot of POSIX/OS specifics that I'm not an expert in, but:

Maybe tb.stop()/wait doesn't actually successfully unmap the shared
memory segments of the buffers; there's a global maximum of segments,
and it 4096 by default (/proc/sys/kernel/shmmni). However, this
shouldn't be the problem at hand: there's an error number for this
condition. And it would be: ENOSPC. Great. The same thing as for No
space left on device; Thank you, Posix.1...

Cheers,
Marcus
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUdL5ZAAoJEAFxB7BbsDrLaIcH/3GZa562FhMLZ7vqafSEQnBG
o3DWr54Wmq1NFbWGVuLTdT4+QFFn5UN5s7RKCdmhJ+KVeqxisV/nCSbH/WfShx8Y
DIq5o28BWsudwNsxtkq94mo57ELgj27fnHItIthqSsPGcUuIX4xszL7YTxsD++ai
Fz6wikE7rt0+01sP5OeIXKpJkXAvWB7VLX+M89tlDCWceF9Nr0nJCleLZCLXSeIq
0n+u7RR3iXU6+RSyDLgK9KNCtNiUyb0p24L4m+jqsAQ/IfT6J/Ip0X5CFLoXg1A3
ocBj6+kT1bq9aztRE2j92ZLVk//CKiuWANCo2lahNUatVehQJ0kANT2DDwp8rNU=
=32+6
-END PGP SIGNATURE-

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

Re: [Discuss-gnuradio] Running out of memory during BER simulations

[Felix W.]

I built GR from source on the machine and the machine is running Ubuntu
14.04 64-bit. So I guess my GR is 64-bit, too.

Actually, while watching the simulation running at the moment, I noticed
that memory usage is indeed increasing slowly (but at a rate that wouldn't
fill up the system memory in days...).

2014-11-25 18:37 GMT+01:00 Marcus Müller mar...@hostalia.de:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hi Felix,


 On 11/25/2014 06:15 PM, Felix W. wrote:
  Between every run, I call tb.stop() followed by tb.wait().
  Unfortunately, after a few runs (around 20), I get the following
  error message:
 
  gr::vmcircbuf_sysv_shm: shmget (2): No space left on device
 I have a suspicion.
 First of all, I know this sounds basic, but you're not using a 32bit
 GR on your 64 bit machine, are you? (that would explain running out of
 RAM faster, just because process memory is so very limited for 32bit
 processes)

 then: vmcircbuf is one of the things I always was kind of hesitant to
 touch (or even try to understand in depth), just because it deals with
 a lot of POSIX/OS specifics that I'm not an expert in, but:

 Maybe tb.stop()/wait doesn't actually successfully unmap the shared
 memory segments of the buffers; there's a global maximum of segments,
 and it 4096 by default (/proc/sys/kernel/shmmni). However, this
 shouldn't be the problem at hand: there's an error number for this
 condition. And it would be: ENOSPC. Great. The same thing as for No
 space left on device; Thank you, Posix.1...

 Cheers,
 Marcus
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1

 iQEcBAEBAgAGBQJUdL5ZAAoJEAFxB7BbsDrLaIcH/3GZa562FhMLZ7vqafSEQnBG
 o3DWr54Wmq1NFbWGVuLTdT4+QFFn5UN5s7RKCdmhJ+KVeqxisV/nCSbH/WfShx8Y
 DIq5o28BWsudwNsxtkq94mo57ELgj27fnHItIthqSsPGcUuIX4xszL7YTxsD++ai
 Fz6wikE7rt0+01sP5OeIXKpJkXAvWB7VLX+M89tlDCWceF9Nr0nJCleLZCLXSeIq
 0n+u7RR3iXU6+RSyDLgK9KNCtNiUyb0p24L4m+jqsAQ/IfT6J/Ip0X5CFLoXg1A3
 ocBj6+kT1bq9aztRE2j92ZLVk//CKiuWANCo2lahNUatVehQJ0kANT2DDwp8rNU=
 =32+6
 -END PGP SIGNATURE-

 ___
 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] Running out of memory during BER simulations

[Marcus Müller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Does increasing kernel.shmmni using sysctl to let's say 16k improve
the situation?

On 11/25/2014 06:37 PM, Marcus Müller wrote:
 Hi Felix,
 
 
 On 11/25/2014 06:15 PM, Felix W. wrote:
 Between every run, I call tb.stop() followed by tb.wait(). 
 Unfortunately, after a few runs (around 20), I get the following 
 error message:
 
 gr::vmcircbuf_sysv_shm: shmget (2): No space left on device
 I have a suspicion. First of all, I know this sounds basic, but
 you're not using a 32bit GR on your 64 bit machine, are you? (that
 would explain running out of RAM faster, just because process
 memory is so very limited for 32bit processes)
 
 then: vmcircbuf is one of the things I always was kind of hesitant
 to touch (or even try to understand in depth), just because it
 deals with a lot of POSIX/OS specifics that I'm not an expert in,
 but:
 
 Maybe tb.stop()/wait doesn't actually successfully unmap the
 shared memory segments of the buffers; there's a global maximum of
 segments, and it 4096 by default (/proc/sys/kernel/shmmni).
 However, this shouldn't be the problem at hand: there's an error
 number for this condition. And it would be: ENOSPC. Great. The same
 thing as for No space left on device; Thank you, Posix.1...
 
 Cheers, Marcus
 
 ___ Discuss-gnuradio
 mailing list Discuss-gnuradio@gnu.org 
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUdMD0AAoJEAFxB7BbsDrL88sIAKE8Ic6WLuvIXcjVl9Rtiwrk
OMGx6iL07PpWDlZBJfU5Twy0O4T+VYSQiwp5DtyMAe60zUH1uBP3eUQ/e9fyFLsN
VV89J9MB4lGlhg8m73kjj8yV2RrM9TttccU9yXHyUiVTQGQ838GRE5QS/CULv3bv
A2hZXX+IVfZLPuxmbd1fuiVDHcX5fxrlPHgLcZRWtOGJkVuvkRYip7mwtHInaVFD
xO6bI8CuujYUAJPKvUbRe3QIyKkxzLi2SPe4Vzn52KqAagwVy1fb8BK109fQ97fU
EPDMedpv5sTbRcB9mhY8SSi3bXaY01C5bLQIT8mw61Tp4D2/AUVdXSJykEc/0HQ=
=o6F6
-END PGP SIGNATURE-

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

Re: [Discuss-gnuradio] Running out of memory during BER simulations

[Felix W.]

That fixed it! Thanks!!

2014-11-25 18:48 GMT+01:00 Marcus Müller mar...@hostalia.de:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Does increasing kernel.shmmni using sysctl to let's say 16k improve
 the situation?

 On 11/25/2014 06:37 PM, Marcus Müller wrote:
  Hi Felix,
 
 
  On 11/25/2014 06:15 PM, Felix W. wrote:
  Between every run, I call tb.stop() followed by tb.wait().
  Unfortunately, after a few runs (around 20), I get the following
  error message:
 
  gr::vmcircbuf_sysv_shm: shmget (2): No space left on device
  I have a suspicion. First of all, I know this sounds basic, but
  you're not using a 32bit GR on your 64 bit machine, are you? (that
  would explain running out of RAM faster, just because process
  memory is so very limited for 32bit processes)
 
  then: vmcircbuf is one of the things I always was kind of hesitant
  to touch (or even try to understand in depth), just because it
  deals with a lot of POSIX/OS specifics that I'm not an expert in,
  but:
 
  Maybe tb.stop()/wait doesn't actually successfully unmap the
  shared memory segments of the buffers; there's a global maximum of
  segments, and it 4096 by default (/proc/sys/kernel/shmmni).
  However, this shouldn't be the problem at hand: there's an error
  number for this condition. And it would be: ENOSPC. Great. The same
  thing as for No space left on device; Thank you, Posix.1...
 
  Cheers, Marcus
 
  ___ Discuss-gnuradio
  mailing list Discuss-gnuradio@gnu.org
  https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1

 iQEcBAEBAgAGBQJUdMD0AAoJEAFxB7BbsDrL88sIAKE8Ic6WLuvIXcjVl9Rtiwrk
 OMGx6iL07PpWDlZBJfU5Twy0O4T+VYSQiwp5DtyMAe60zUH1uBP3eUQ/e9fyFLsN
 VV89J9MB4lGlhg8m73kjj8yV2RrM9TttccU9yXHyUiVTQGQ838GRE5QS/CULv3bv
 A2hZXX+IVfZLPuxmbd1fuiVDHcX5fxrlPHgLcZRWtOGJkVuvkRYip7mwtHInaVFD
 xO6bI8CuujYUAJPKvUbRe3QIyKkxzLi2SPe4Vzn52KqAagwVy1fb8BK109fQ97fU
 EPDMedpv5sTbRcB9mhY8SSi3bXaY01C5bLQIT8mw61Tp4D2/AUVdXSJykEc/0HQ=
 =o6F6
 -END PGP SIGNATURE-

 ___
 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] running uhd_fft with a rtlsdr stick

[Ben Hiett]

is it possible to run uhd_fft directly from the IQ data coming over usb from an 
rtlsdr stick?
or is this only for use with an ettus usrp device?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] running uhd_fft with a rtlsdr stick

[mleech]

 

 If you want to do the equivalent of uhd_fft for non-Ettus devices, just
use osmocom_fft 

On 2014-09-08 11:52, Ben Hiett wrote: 

 is it possible to run uhd_fft directly from the IQ data coming over usb from 
 an rtlsdr stick? 
 or is this only for use with an ettus usrp device? 
 
 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]
 

Links:
--
[1] 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] running uhd_fft with a rtlsdr stick

[Ben Hiett]

should I already have that installed due having installed gr-osmosdr or do I 
need to get it from somewhere else?

I was thinkinkg of having a go with multimode.py as well, thats your piece of 
work i think?




On Monday, 8 September 2014, 16:57, mle...@ripnet.com mle...@ripnet.com 
wrote:
 


 If you want to do the equivalent of uhd_fft for non-Ettus devices, just use 
osmocom_fft
 
 
 
 
On 2014-09-08 11:52, Ben Hiett wrote:
is it possible to run uhd_fft directly from the IQ data coming over usb from an 
rtlsdr stick?
 
or is this only for use with an ettus usrp device?

___
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] running multiple flow graphs simultaneously

[Martin Braun]

On 04/01/2014 11:29 PM, Rob Miller wrote:
 Is it possible to run more than one top_block at a time in gnuradio
 3.7.x?  I have an application where I wish to run an additional flow
 graph periodically.  I have set up a thread that grabs samples via a
 probe from my main flow graph that is running all of the time, and uses
 that data to source another flow graph.  Everything appears to be

Yes, you can do that.
It might not be what you want -- running 2 top_blocks is a bit like
running 2 processes with one tb each.
You can have a disconnected flow graph in one top block by making each
FG a hier block, and then adding that to the top block.

 running, however I want to be certain that I'm not doing something
 terribly wrong --- especially since two relevant sources of information
 seem to contradict my current mode of operation:
 
 
 From the Python application writing tutorial (June 2008)
 
 http://gnuradio.org/redmine/projects/gnuradio/wiki/TutorialsWritePythonApplications
 
 
 From a January 2012 gnuradio mailing list post:
 
 http://lists.gnu.org/archive/html/discuss-gnuradio/2012-01/msg00145.html

It used to be that you could only have 1 top_block per process. The wiki
page is not up to date.

M

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

[Discuss-gnuradio] running multiple flow graphs simultaneously

[Rob Miller]

Hi -


Is it possible to run more than one top_block at a time in gnuradio 3.7.x?  I 
have an application where I wish to run an additional flow graph periodically.  
I have set up a thread that grabs samples via a probe from my main flow graph 
that is running all of the time, and uses that data to source another flow 
graph.  Everything appears to be running, however I want to be certain that I'm 
not doing something terribly wrong --- especially since two relevant sources of 
information seem to contradict my current mode of operation:


From the Python application writing tutorial (June 2008)
http://gnuradio.org/redmine/projects/gnuradio/wiki/TutorialsWritePythonApplications


From a January 2012 gnuradio mailing list post:
http://lists.gnu.org/archive/html/discuss-gnuradio/2012-01/msg00145.html


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

Re: [Discuss-gnuradio] Running Flowgraph some a certain period of time

[Marcus Müller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Ruecan,

On 12.03.2014 22:52, Ruecan wrote:
 Hello GR,
 
 * Is there a way how to run my flowgraph for a given number of 
 minutes/seconds then stop it.
Of course.
If what you really want to do is doing a certain number of samples,
the head block is what you need.

If your end condition really comes from outside, you should use
something like topblock.start(), [wait 5s, e.g. using time.sleep()],
toblock.stop(), topblock.wait()
 
 * I'd like to know too how to reconfigure my flowgraph (after I
 stop it from runtime) and resume its run after I changed for
 example the signal source at the begin of the flowgraph.

 
 I tried:
 
 My_flowgraph Description
 
 def MyRoutine(args): global tb . if (condition): tb.stop() 
 myModifiedflowgraph.myModifiedflowgraph(args) . . ..
 
 if __name__ == '__main__': global tb . . 
 threading.Timer(10,myRoutine).start() tb.Run(True)
 
 My point here is that I need to run myModifiedflowgraph for a
 certain period of time then stop it and resume tb. FYI
 myModifiedflowgraph is the name of the other py script which
 contain the modifiedflowgraph called also myModifiedflowgraph. Any
 hints or explanations are well appreciated
 
This is not really reconfiguration, as far as I understand your
architecture. It is stopping and starting two different flowgraphs -
which is ok in theory, but you have to find a way to share the
hardware between the two. Which usually defeats the purpose of having
reconfigurable flowgraphs-adjusting your receiver structure to
changing environment.
In this case, it might be a good choide to disconnect() only the
blocks in tb that need to be replaced and connect() the new ones.

Greetings,
Marcus
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTIWsRAAoJEBQ6EdjyzlHtq3gIAIfEwZNuSgL9iZxETuy1i8Wa
9eAk5I2SQ2gyFSFKXlizeYTTZ9apCC81VD3fMYt8foYfVcEY+TL4orOFTUbrbeok
VD6+T8/gLxErnYa37YiYXZBRjIX7SzFdrLt2eiUZBHMF0HDi4RJzJM594SBnDNyI
OvqtY1pTcW+B4OEVS+BZgI/pj8zj6TrP+0Mg3JiyzKMoi4Yhvf3fcFQ9PXPmk7gW
58lzl8GRFBi0Cexi9Q56pyaM1MqPJ0kflfz8rSydQjmS5b4HfuQk9VS6FT4P008e
E0Vg0H71iNYXW83a0ZvbT9K5lXPvUdIGW/pQw9yY21OdqckKtezq64MzHQ6pwfc=
=TSGr
-END PGP SIGNATURE-

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

Re: [Discuss-gnuradio] Running GNU Radio on Linux in VMware Workstation

[Tom Rondeau]

On Mon, Mar 10, 2014 at 5:08 PM, Mike Harpe m...@mikeharpe.com wrote:
 I have been working for a week or so on getting GNU Radio going on a Debian
 Linux platform running inside a VM.

 GNU Radio is compiled and runs fine. The VM sees my Funcube Pro+ dongle.
 Using 'plughw:0,0' got rid of the audio stuttering problem. After struggling
 with a couple of the demo flowgraphs I downloaded and built gqrx.

 It runs. I can tune it to the local NOAA Weather Radio transmitter. I use
 that for testing because its very strong where I am. I have the same problem
 there that I have in GNU Radio: no receive audio.

 Can anyone give me some advice how to proceed? To answer the one question,
 yes, I am pursuing building a Debian system on a flash drive that I can boot
 natively.

 Mike Harpe, N4PLE
 Sellersburg, IN, USA


You can specify the audio output device globally for your system by
editing $prefix/etc/gnuradio/conf.d/gr-audio-alsa.conf (I'm assuming
that's what you are working with given the use of plughw). You can set
that 'plughw:0,0' in as the 'default_output_device' argument. If you
are running PulseAudio, you can use 'pulse' for this, too, which tends
to work more reliably for me these days.

Tom

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

[Discuss-gnuradio] Running GNU Radio on Linux in VMware Workstation

[Mike Harpe]

I have been working for a week or so on getting GNU Radio going on a Debian
Linux platform running inside a VM.

GNU Radio is compiled and runs fine. The VM sees my Funcube Pro+ dongle.
Using 'plughw:0,0' got rid of the audio stuttering problem. After
struggling with a couple of the demo flowgraphs I downloaded and built gqrx.

It runs. I can tune it to the local NOAA Weather Radio transmitter. I use
that for testing because its very strong where I am. I have the same
problem there that I have in GNU Radio: no receive audio.

Can anyone give me some advice how to proceed? To answer the one question,
yes, I am pursuing building a Debian system on a flash drive that I can
boot natively.

Mike Harpe, N4PLE
Sellersburg, IN, USA
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Running GMSK mod/demod test

[Florian Schlembach]

To put it in simple words, I am wondering why the GMSK-Mod blocks always 
outputs 8192 bits - no matter when I input 50 bits or 255 bits.


Is there a GMSK-burst-like modulation happening?

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

[Discuss-gnuradio] Running GMSK mod/demod test

[Florian Schlembach]

I trying to run a GMSK mod/demod test under GRC. My objective is to 
create a single GSM-like burst and to store it in a file. The waveform 
should have defined bits (by now I assume them to be random).


Thus I created a flowgraph that looks like this

Random Source (fixed # of samples, no repeat) - Packet Encoder - GMSK 
Mod (-File Sink gmsk_tx) - GMSK Demod - Packet Decoder - File Sink 
(integer of bits_out)


1. If I keep increasing the number of bits in Random Source, I have 
noticed that the number generated complex samples (I read them into 
MATLAB using read_complex_binary) stays constant at 8496 complex samples 
until 255 modulated bits. From 255 to 383 it is 2*8496, from 384 to ... 
it is 3*8496. Are these the bursts? Why are the bound to integers of 8496?


2. When forming a loopback, reading the modulated signal and 
demodulating it, the bits_out are not demodulated when reading the file 
bits_out via read_int_binary. Whats wrong with the flowgraph?


I attached the respective .grc file. I appreciate any help!

-Flo


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

Re: [Discuss-gnuradio] Running older USRP scripts with GNURadio 3.60

[Tom Rondeau]

On Tue, Oct 16, 2012 at 6:34 PM, Tom Hendrick sdtom...@yahoo.com wrote:
 Hello,

 I have ubuntu 12.04 and GNURadio 3.6.2.  I was trying to run some older
 scripts which uses the USRP.  These scripts were made with GNURadio
 Companion about 3 years ago, and then I added some extra menu options by
 manually editing the python script made by GRC.

 Unfortunately when I run the scripts, I get a can't find USRP type error.
 I understand in the newer GNURadio installations that USRP is replaced with
 UHD.  Does anyone know of an easy way to run older scripts that call the
 USRP class?  I am not experienced enough to convert all the old scripts.  I
 would likely have to make new ones with the newer GNURadio Companion
 installation and add all the extra menu features again manually.

 Thank you,
 Tom

Tom,
Honestly, your best bet is to update the old scripts to use the UHD
interface. It's not a very big switch between the old and new; really,
it's mostly syntactic changes. Also, to be blunt, there is a way to
use the old libusrp drivers, but if you aren't experienced enough to
update to UHD, trying to mix and match the old libusrp with new GNU
Radio is also going to be difficult.

My suggestion would be to go into GRC and create just a simple UHD
program. Just drop down a UHD source and drive it into a GUI sink.
When you build/run this script, you can look at the build Python for
the syntax you need to copy over to your old scripts.

Hope that helps.

Tom

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

[Discuss-gnuradio] Running older USRP scripts with GNURadio 3.60

[Tom Hendrick]

Hello,

I have ubuntu 12.04 and GNURadio 3.6.2.  I was trying to run some older scripts 
which uses the USRP.  These scripts were made with GNURadio Companion about 3 
years ago, and then I added some extra menu options by manually editing the 
python script made by GRC.

Unfortunately when I run the scripts, I get a can't find USRP type error.  I 
understand in the newer GNURadio installations that USRP is replaced with UHD.  
Does anyone know of an easy way to run older scripts that call the USRP class?  
I am not experienced enough to convert all the old scripts.  I would likely 
have to make new ones with the newer GNURadio Companion installation and add 
all the extra menu features again manually.

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

[Discuss-gnuradio] Running qa code for gr_fxpt class

[Philip Balister]

I am working on improving the wfm_tx transmitter for the e100 and am in
the process of replacing calls to libm for sin/cos with the fixed point
(argument only) version already in gnuradio.

It does not look like the qa_code actually runs though (cmake build).
Any hints on getting the qa code to run?

Code is here:

https://github.com/balister/GNU-Radio/commit/c8f59bae854cccb6897c27424cce1a428c337286

Philip

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

Re: [Discuss-gnuradio] Running qa code for gr_fxpt class

[Tom Rondeau]

On Tue, Mar 13, 2012 at 10:26 AM, Philip Balister phi...@balister.orgwrote:

 I am working on improving the wfm_tx transmitter for the e100 and am in
 the process of replacing calls to libm for sin/cos with the fixed point
 (argument only) version already in gnuradio.

 It does not look like the qa_code actually runs though (cmake build).
 Any hints on getting the qa code to run?

 Code is here:


 https://github.com/balister/GNU-Radio/commit/c8f59bae854cccb6897c27424cce1a428c337286

 Philip


What makes you think that it's not running? I tried it and the QA code in
the t3() test runs. I purposefully made an error in the calculation, and it
fails as expected.

I run 'ctest -V -R core' to just run this test with verbose output to see
the cout call, too.

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

Re: [Discuss-gnuradio] Running qa code for gr_fxpt class

[Philip Balister]

On 03/13/2012 12:30 PM, Tom Rondeau wrote:
 On Tue, Mar 13, 2012 at 10:26 AM, Philip Balister phi...@balister.orgwrote:
 
 I am working on improving the wfm_tx transmitter for the e100 and am in
 the process of replacing calls to libm for sin/cos with the fixed point
 (argument only) version already in gnuradio.

 It does not look like the qa_code actually runs though (cmake build).
 Any hints on getting the qa code to run?

 Code is here:


 https://github.com/balister/GNU-Radio/commit/c8f59bae854cccb6897c27424cce1a428c337286

 Philip

 
 What makes you think that it's not running? I tried it and the QA code in
 the t3() test runs. I purposefully made an error in the calculation, and it
 fails as expected.
 
 I run 'ctest -V -R core' to just run this test with verbose output to see
 the cout call, too.

It looks like my attempt at forcing an error had a bug :)

Looks fine now.

Philip

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

Re: [Discuss-gnuradio] Running qa code for gr_fxpt class

[Tom Rondeau]

On Tue, Mar 13, 2012 at 1:23 PM, Philip Balister phi...@balister.orgwrote:

 On 03/13/2012 12:30 PM, Tom Rondeau wrote:
  On Tue, Mar 13, 2012 at 10:26 AM, Philip Balister phi...@balister.org
 wrote:
 
  I am working on improving the wfm_tx transmitter for the e100 and am in
  the process of replacing calls to libm for sin/cos with the fixed point
  (argument only) version already in gnuradio.
 
  It does not look like the qa_code actually runs though (cmake build).
  Any hints on getting the qa code to run?
 
  Code is here:
 
 
 
 https://github.com/balister/GNU-Radio/commit/c8f59bae854cccb6897c27424cce1a428c337286
 
  Philip
 
 
  What makes you think that it's not running? I tried it and the QA code in
  the t3() test runs. I purposefully made an error in the calculation, and
 it
  fails as expected.
 
  I run 'ctest -V -R core' to just run this test with verbose output to see
  the cout call, too.

 It looks like my attempt at forcing an error had a bug :)

 Looks fine now.

 Philip


Excellent!

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?

[Florian Schlembach]

The XCVR2450 hardware is incapable of full-duplex operation. It *cannot*
transmit and receive at the same time.


Yes, you are right but consider we are transmitting ping requests just 
for a very short moment (since they are also containing only 84 bytes) 
with a frequency of 1 Hz. Hence, we are occupying the channel only for a 
very short-termed moment.


We have right now in this moment found out or at least got a clue why it 
isn't running.
We have inserted a sleep of roughly 50ms before the 
self.tb.txpath.send_pkt(payload) in order to give the RX/TX switching 
some time. The packet is now sent back and the ping request indicates a 
delay of 56ms (including the sleeping delay of 50ms).


Does anybody has a clue why the RX/TX switching is not established fast 
enough? Is there some code missing what dictates the UHD interface to 
switch? In another application using UHD natively we are not 
experiencing such a strange behavior.



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

[Florian Schlembach]

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


Why is that unrelated to the purpose of tunnel.py? Shouldnt a simple 
ping request be a basic application of using this TUN/TAP application?
Anyway, we have now set up the routing table correctly by using TUN 
instead of TAP.
As we are transmitting the ping from one of the USRPs, we are also 
receiving them at the RX-USRP which is answering with a ping reply:


RX-USRP:

-
TIMEOUT
Rx: ok = True  len(payload) =   84
Tx: len(payload) =   84
send now!
UTIMEOUT
-

Observing the IP dataflow via Wireshark (at RX-USRP) confirms that.
However, we are NOT receiving this ping reply and the transmitting USRP.
It seems, like it cannot transmit and receive simultaneously. Exactky 
the same happens if we swap the role of transmitting and receiving USRPs.


Anybody has an idea how we could overcome this problem? Basically, we 
want to measure the latency of a real application.


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

[Florian Schlembach]

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


Why is that unrelated to the purpose of tunnel.py? Shouldnt a simple 
ping request be a basic application of using this TUN/TAP application?
Anyway, we have now set up the routing table correctly by using TUN 
instead of TAP.
As we are transmitting the ping from one of the USRPs, we are also 
receiving them at the RX-USRP which is answering with a ping reply:


RX-USRP:

-
TIMEOUT
Rx: ok = True  len(payload) =   84
Tx: len(payload) =   84
send now!
UTIMEOUT
-

Observing the IP dataflow via Wireshark (at RX-USRP) confirms that.
However, we are NOT receiving this ping reply and the transmitting USRP.
It seems, like it cannot transmit and receive simultaneously. Exactky 
the same happens if we swap the role of transmitting and receiving USRPs.


Anybody has an idea how we could overcome this problem? Basically, we 
want to measure the latency of a real application.



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

[mleech]

  

The XCVR2450 hardware is incapable of full-duplex operation. It
*cannot* transmit and receive at the same time. 

On Wed, 01 Feb 2012
18:05:53 +0100, Florian Schlembach wrote: 

 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...
 Why is that unrelated to
the purpose of tunnel.py? Shouldnt a simple ping request be a basic
application of using this TUN/TAP application? Anyway, we have now set
up the routing table correctly by using TUN instead of TAP. As we are
transmitting the ping from one of the USRPs, we are also receiving them
at the RX-USRP which is answering with a ping reply: RX-USRP: - TIMEOUT
Rx: ok = True len(payload) = 84 Tx: len(payload) = 84 send now! UTIMEOUT
- Observing the IP dataflow via Wireshark (at RX-USRP) confirms that.
However, we are NOT receiving this ping reply and the transmitting USRP.
It seems, like it cannot transmit and receive simultaneously. Exactky
the same happens if we swap the role of transmitting and receiving
USRPs. Anybody has an idea how we could overcome this problem?
Basically, we want to measure the latency of a real application.
___

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

[Florian Schlembach]

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

[Tom Rondeau]

On Tue, Jan 31, 2012 at 8:28 AM, Florian Schlembach 
florian.schlemb...@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
___
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?

[Tom Rondeau]

On Mon, Jan 30, 2012 at 11:12 AM, Martin Braun martin.br...@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?

[Andrew Davis]

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 t...@trondeau.com wrote:

 On Mon, Jan 30, 2012 at 11:12 AM, Martin Braun martin.br...@kit.eduwrote:

 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


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

[Marcus D. Leech]

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

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

[Marcus D. Leech]

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

[Florian Schlembach]

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

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

[Josh Blum]

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?

[Andrew Davis]

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 mle...@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 Consortiumhttp://www.sbrac.org


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

[Marcus D. Leech]

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

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

[Martin Braun]

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



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

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

[Florian Schlembach]

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
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Running python-gtk with GNURadio

[Fon, Rithirong Thandee]

Hi all,

I'm trying to create a GUI for my GNURadio program using python-gtk on a
USRP E100. I have GNURadio and pythong-gtk working separately. But now that
I'm combining them, the graphic windows goes blank and waits for the
GNURadio part to finish. Is there a better way to do this?

Thank you,
Rithirong Thandee
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Running python-gtk with GNURadio

[Ben Hilburn]

Fon -

Can you detail how you are combining them?  If you are executing GNU Radio
stuff from the primary thread in your GUI application, it will stop
re-drawing the window (because the thread is busy executing GNU Radio).

Also, all GUI updates must happen from your main thread.

Cheers,
Ben

On Fri, Jan 13, 2012 at 1:07 PM, Fon, Rithirong Thandee rthan...@vt.eduwrote:

 Hi all,

 I'm trying to create a GUI for my GNURadio program using python-gtk on a
 USRP E100. I have GNURadio and pythong-gtk working separately. But now that
 I'm combining them, the graphic windows goes blank and waits for the
 GNURadio part to finish. Is there a better way to do this?

 Thank you,
 Rithirong Thandee

 ___
 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] Running Ubuntu 11.04 AMD64; Getting crazy latency results, about 20ms

[Colby Boyer]

Hi all,

I'm running a duplex system on the USRP1; using UHD drivers (about 1 month
old). For the sample rates, I have 640KHz to the USRP and 1MHz from the
USRP. The turn around time for a simple amplitude detected signal is approx
20ms, which is crazy high. Btw, I'm measuring the latency (approx) by
observing the nitems_written() method for the block that produces samples
for the sync.

I'm running UHD and gnuradio with real time threading enabled and giving the
gnuradio app a nice of -20. Since this happens before any math occurs, I
assume the kernel is lagging on this. Could switching to a modified kernel
with realtime improvement patches help?

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

Re: [Discuss-gnuradio] Running Ubuntu 11.04 AMD64; Getting crazy latency results, about 20ms

[Thomas Tsou]

On Wed, Jul 27, 2011 at 1:23 PM, Colby Boyer colby.bo...@gmail.com wrote:
 Hi all,
 I'm running a duplex system on the USRP1; using UHD drivers (about 1 month
 old). For the sample rates, I have 640KHz to the USRP and 1MHz from the
 USRP. The turn around time for a simple amplitude detected signal is approx
 20ms, which is crazy high. Btw, I'm measuring the latency (approx) by
 observing the nitems_written() method for the block that produces samples
 for the sync.
 I'm running UHD and gnuradio with real time threading enabled and giving the
 gnuradio app a nice of -20. Since this happens before any math occurs, I
 assume the kernel is lagging on this. Could switching to a modified kernel
 with realtime improvement patches help?

The short answer is that using the RT patch series won't perform any
magic and bring across the board reductions in measured latencies. The
longer answer is, of course, more complicated. If you want
straightforward solutions, try removing other peripherals from the USB
bus and disabling all power management (preferably from the kernel).
The latter can be particularly sinister when it comes to tracking down
latency bugs.

Once upon a time, I wrote a kernel module to handle a hard interrupt
off of a parallel port and trigger responses from within kernel space
(out another pin) and userspace (submitting transfers to libusrp). An
external scope was was used for timing measurement. Response times
were on average in the single and 10's of microseconds respectively,
but differed drastically based on many factors. The main ones were CPU
load, power management, and other devices on the USB bus.

When it comes to RT patches, you need to consider that the objective
is typically containing maximum latencies and not necessarily minimal
or average times. In certain cases, average latencies using RT code
may be even be higher than the mainline version.

When I ran the tests, differences between mainline (somewhere around
2.6.31) and RT series kernels were initially limited, but became
apparent when running at near 100% CPU load. In contrived cases, the
maximum latency on the normal kernel could increase without bound,
which would be more limited on the RT kernel.

To sum it up, RT changes to the kernel will have an effect, but it
probably won't be immediately obvious. I would start from more obvious
areas - for example by seeing what power management is up to.

  Thomas

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

Re: [Discuss-gnuradio] Running Ubuntu 11.04 AMD64; Getting crazy latency results, about 20ms

[Colby Boyer]

On Wed, Jul 27, 2011 at 4:16 PM, Thomas Tsou tt...@vt.edu wrote:

 On Wed, Jul 27, 2011 at 1:23 PM, Colby Boyer colby.bo...@gmail.com
 wrote:
  Hi all,
  I'm running a duplex system on the USRP1; using UHD drivers (about 1
 month
  old). For the sample rates, I have 640KHz to the USRP and 1MHz from the
  USRP. The turn around time for a simple amplitude detected signal is
 approx
  20ms, which is crazy high. Btw, I'm measuring the latency (approx) by
  observing the nitems_written() method for the block that produces samples
  for the sync.
  I'm running UHD and gnuradio with real time threading enabled and giving
 the
  gnuradio app a nice of -20. Since this happens before any math occurs, I
  assume the kernel is lagging on this. Could switching to a modified
 kernel
  with realtime improvement patches help?

 The short answer is that using the RT patch series won't perform any
 magic and bring across the board reductions in measured latencies. The
 longer answer is, of course, more complicated. If you want
 straightforward solutions, try removing other peripherals from the USB
 bus and disabling all power management (preferably from the kernel).
 The latter can be particularly sinister when it comes to tracking down
 latency bugs.

 Once upon a time, I wrote a kernel module to handle a hard interrupt
 off of a parallel port and trigger responses from within kernel space
 (out another pin) and userspace (submitting transfers to libusrp). An
 external scope was was used for timing measurement. Response times
 were on average in the single and 10's of microseconds respectively,
 but differed drastically based on many factors. The main ones were CPU
 load, power management, and other devices on the USB bus.

 When it comes to RT patches, you need to consider that the objective
 is typically containing maximum latencies and not necessarily minimal
 or average times. In certain cases, average latencies using RT code
 may be even be higher than the mainline version.

 When I ran the tests, differences between mainline (somewhere around
 2.6.31) and RT series kernels were initially limited, but became
 apparent when running at near 100% CPU load. In contrived cases, the
 maximum latency on the normal kernel could increase without bound,
 which would be more limited on the RT kernel.

 To sum it up, RT changes to the kernel will have an effect, but it
 probably won't be immediately obvious. I would start from more obvious
 areas - for example by seeing what power management is up to.

  Thomas


Thanks for the detailed reply Thomas!

I'll give the power management changes (from the kernel and from BIOS) a
shot, then will try the ubuntu linux-rt kernel from their ubuntu studio
repo.

Are there any particular power options to change on the Kernel?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Running wx gui widgets over xforwarding ssh connection fails

[Phelps Williams]

I receive the following error when connecting to a ubuntu 10.10 platform
from a debian lenny machine:

pwilliams@ubuntu:~/gnuradio_test$ ./top_block.py
linux; GNU C++ version 4.4.5; Boost_104200; UHD_003.000.001-release

Xlib:  extension RANDR missing on display localhost:10.0.
Segmentation fault

Several of the systems I work on run on remote servers and it would be
really nice to view the pretty wx fft display remotely.  Has anybody had
success with this?

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

Re: [Discuss-gnuradio] Running wx gui widgets over xforwarding ssh connection fails

[Marcus D. Leech]

I receive the following error when connecting to a ubuntu 10.10 
platform from a debian lenny machine:


pwilliams@ubuntu:~/gnuradio_test$ ./top_block.py
linux; GNU C++ version 4.4.5; Boost_104200; UHD_003.000.001-release

Xlib:  extension RANDR missing on display localhost:10.0.
Segmentation fault

Several of the systems I work on run on remote servers and it would be 
really nice to view the pretty wx fft display remotely.  Has anybody 
had success with this?


-Phelps
The WX widgets use OpenGL to render some items, and OpenGL seems to want 
certain X server extensions to be available to it.


You could try setting and exporting:

export LIBGL_ALWAYS_SOFTWARE=1

Before starting your remotely-displayed WxPython program.  This is 
supposed to force OpenGL to use software-only rendering, rather
  than trying to find rendering extensions in the X server.  I haven't 
found this to be a reliable way to make it work, but sometimes it
  does.  The problem isn't in Gnu Radio, per se, but the OpenGL library 
that WxPython uses for produce some of the display elements--like

  the graphic sinks.


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

[Discuss-gnuradio] running gr-uhd on usrp e100

[Fon, Rithirong Thandee]

Hello,

I'm trying to run a ucla zigbee phy code (
https://www.cgran.org/wiki/UCLAZigBee) with gr-uhd on the usrp e100. But I'm
getting an error

Traceback (most recent call last):
   File ./cc2420_txtest_uhd.py, line 10, in module
 from gnuradio import uhd
   File /usr/lib/python2.6/site-packages/gnuradio/uhd/__init__.py, line
 27, in module
 from uhd_swig import *
   File /usr/lib/python2.6/site-packages/gnuradio/uhd/uhd_swig.py, line
 24, in module
 _uhd_swig = swig_import_helper()
   File /usr/lib/python2.6/site-packages/gnuradio/uhd/uhd_swig.py, line
 20, in swig_import_helper
 _mod = imp.load_module('_uhd_swig', fp, pathname, description)
 ImportError: /usr/lib/libgnuradio-uhd-3.4git.so.0: undefined symbol:
 _ZN3uhd4usrp11single_usrp9ALL_GAINSE


Has anyone worked with gr-uhd on usrp e100? Can someone help? I already
installed gr-uhd and uhd installed.


Thank you so much!
Fon
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Running GNU Radio before you install it

[Philip Balister]

I've got gnuradio cross compiled for the armv7 and have it NFS mounted 
on the target hw. Is there an easy way to test gnuradio by running 
applications out of the build tree?


I know about running make check on the target, but I am interested in 
testing more complex flowgraphs.


Philip

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

Re: [Discuss-gnuradio] Running GNU Radio before you install it

[Eric Blossom]

On Mon, Aug 30, 2010 at 08:42:51PM -0400, Philip Balister wrote:
 I've got gnuradio cross compiled for the armv7 and have it NFS
 mounted on the target hw. Is there an easy way to test gnuradio by
 running applications out of the build tree?

Easy way?  No.

 I know about running make check on the target, but I am interested
 in testing more complex flowgraphs.

Python or C++?

For python, take a look at gnuradio-core/src/python/gnuradio/gr/Makefile.am and
run_tests for clues about how you might be able to move forward.
(Note that we don't have any commitment to keep doing it the same way...)

Eric

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

Re: [Discuss-gnuradio] running OFDM on USRP2

[bin zan]

Ian,
  Yes, we use usrp2_fft.py to find and set the property rx_gain first.

Bin

On Wed, Mar 31, 2010 at 1:11 AM, Ian Holland ian.holl...@rlmgroup.com.auwrote:

 I have been inactive on this for some time due to other issues with my
 USRP2s. However, I have been able to look into this again now, with
 Veljko's modified code. I run as root, and also had the realtime
 scheduling enabled, however on the receive side I see nothing until the
 transmitter stops transmitting, at which time I see timeout.

 This seems to be the same problem that Bin had (except without the
 realtime scheduling issue). Bin, did you end up resolving this issue?

 Cheers

 Ian.


 -Original Message-
 From: discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org
 [mailto:discuss-gnuradio-bounces+ian.hollanddiscuss-gnuradio-bounces%2Bian.holland
 =rlmgroup.com...@gnu.org] On
 Behalf Of Tom Rondeau
 Sent: Thursday, 4 February 2010 11:56 PM
 To: bin zan
 Cc: discuss-gnuradio@gnu.org
 Subject: Re: [Discuss-gnuradio] running OFDM on USRP2

 On Wed, Feb 3, 2010 at 1:55 PM, bin zan zanbin2...@gmail.com wrote:
  Hi Tom,
  In our case, even with script from Veljko, the OFDM receiver doesn't
 show
  any thing. And we always see usrp2: failed to enable realtime
 scheduling.
  Do you think that will cause problem?
 
  Thanks,
  Bin


 No, that message is just telling you that you don't have permissions
 to run it at the highest priority. It means you won't be able to run
 as fast, but that shouldn't be the cause of your problems.

 Tom


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

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

RE: [Discuss-gnuradio] running OFDM on USRP2

[Ian Holland]

I have been inactive on this for some time due to other issues with my
USRP2s. However, I have been able to look into this again now, with
Veljko's modified code. I run as root, and also had the realtime
scheduling enabled, however on the receive side I see nothing until the
transmitter stops transmitting, at which time I see timeout.

This seems to be the same problem that Bin had (except without the
realtime scheduling issue). Bin, did you end up resolving this issue?

Cheers

Ian.
 

-Original Message-
From: discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org
[mailto:discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org] On
Behalf Of Tom Rondeau
Sent: Thursday, 4 February 2010 11:56 PM
To: bin zan
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] running OFDM on USRP2

On Wed, Feb 3, 2010 at 1:55 PM, bin zan zanbin2...@gmail.com wrote:
 Hi Tom,
 In our case, even with script from Veljko, the OFDM receiver doesn't
show
 any thing. And we always see usrp2: failed to enable realtime
scheduling.
 Do you think that will cause problem?

 Thanks,
 Bin


No, that message is just telling you that you don't have permissions
to run it at the highest priority. It means you won't be able to run
as fast, but that shouldn't be the cause of your problems.

Tom


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


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

[Discuss-gnuradio] Running benchmark_rx.py in debugging mode

[amarnath alapati]

hi everyone,
   Is there any way for me to run the benchmark_tx and
benchmark_rx.py files in debugging mode so that I can see the entire flow
structure? I am curious to know the steps that take place from the calling
of the python script to the point where the modulated symbols are
transmitted via the USB2.0.
Regards,
Amarnath
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Running benchmark_rx.py in debugging mode

[Jason Uher]

On Mon, Feb 22, 2010 at 3:55 AM, amarnath alapati
amarnath.alap...@gmail.com wrote:
 hi everyone,
            Is there any way for me to run the benchmark_tx and
 benchmark_rx.py files in debugging mode so that I can see the entire flow
 structure? I am curious to know the steps that take place from the calling
 of the python script to the point where the modulated symbols are
 transmitted via the USB2.0.
 Regards,
 Amarnath

I'm not sure exactly what you mean by 'debugging mode'.  You can
attach a running flowgraph to gdb
(http://www.gnu.org/software/gnuradio/doc/howto-write-a-block.html#debugging),
but I would think that that's lower level stuff than you are looking
for, and the multi-threaded scheduler makes it difficult to monitor
specific flows for a less-than-expert gdb user.

At the current point in time there doesn't seem to be a way to 'single
step' through a flow graph and monitor the inputs and outputs, no
'gnuradio debugger' as it were.  I think this would be a nice feature
to have, both in grc and as command line tool, but I think it's a
pretty hard thing to implement given the current code.

You can turn on logging the benchmark_*x files which will give you the
modulation steps only, if that is what you are interested in.  You
will have to view the log files with octave or matlab and synchronize
them yourself.

Jason


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

Re: [Discuss-gnuradio] Running benchmark_rx.py in debugging mode

[Eric Blossom]

On Mon, Feb 22, 2010 at 07:34:01AM -0600, Jason Uher wrote:
 On Mon, Feb 22, 2010 at 3:55 AM, amarnath alapati
 amarnath.alap...@gmail.com wrote:
  hi everyone,
             Is there any way for me to run the benchmark_tx and
  benchmark_rx.py files in debugging mode so that I can see the entire flow
  structure? I am curious to know the steps that take place from the calling
  of the python script to the point where the modulated symbols are
  transmitted via the USB2.0.
  Regards,
  Amarnath

You can turn logging on.

Try 

  $ benchmark_rx.py --help

You'll have to look at the code to understand what's in each log file.

Eric


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

Re: [Discuss-gnuradio] running OFDM on USRP2

[Tom Rondeau]

On Wed, Feb 3, 2010 at 1:55 PM, bin zan zanbin2...@gmail.com wrote:
 Hi Tom,
 In our case, even with script from Veljko, the OFDM receiver doesn't show
 any thing. And we always see usrp2: failed to enable realtime scheduling.
 Do you think that will cause problem?

 Thanks,
 Bin


No, that message is just telling you that you don't have permissions
to run it at the highest priority. It means you won't be able to run
as fast, but that shouldn't be the cause of your problems.

Tom


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

Re: [Discuss-gnuradio] running OFDM on USRP2

[Eric Blossom]

On Thu, Feb 04, 2010 at 07:25:47AM -0600, Tom Rondeau wrote:
 On Wed, Feb 3, 2010 at 1:55 PM, bin zan zanbin2...@gmail.com wrote:
  Hi Tom,
  In our case, even with script from Veljko, the OFDM receiver doesn't show
  any thing. And we always see usrp2: failed to enable realtime scheduling.
  Do you think that will cause problem?
 
  Thanks,
  Bin
 
 
 No, that message is just telling you that you don't have permissions
 to run it at the highest priority. It means you won't be able to run
 as fast, but that shouldn't be the cause of your problems.
 
 Tom

To enable real-time scheduling (highly recommended), do this:

Ensure that you are in the usrp group, and then add
this line to the end of /etc/security/limits.conf:

@usrp-   rtprio  50

Log out, then back in, and the message should go away.

Eric


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

Re: [Discuss-gnuradio] running OFDM on USRP2

[Tom Rondeau]

On Tue, Feb 2, 2010 at 4:34 PM, Anu000 anupama.puro...@gmail.com wrote:

 Hi,
 We did try the below command on two USRP2s coneected via a SMA Cable (Tx-Rx)
 with freq = 25M  however it returned the following error on both sides

 At Rx side it shows like the below -

 [r...@gnuradio1 ofdm]# ./benchmark_ofdm_rx.py -f 25M -d 256 --fft-length=64
 --occupied-tones=32 --cp-length=4
 usrp: failed to find usrp[0]
 Traceback (most recent call last):
  File ./benchmark_ofdm_rx.py, line 210, in module
    main()
  File ./benchmark_ofdm_rx.py, line 199, in main
    tb = my_top_block(rx_callback, options)
  File ./benchmark_ofdm_rx.py, line 51, in __init__
    self._setup_usrp_source()
  File ./benchmark_ofdm_rx.py, line 70, in _setup_usrp_source
    fusb_nblocks=self._fusb_nblocks)
  File /usr/lib/python2.6/site-packages/gnuradio/usrp/usrp_swig.py, line
 1699, in source_c
    return _usrp_swig.source_c(*args, **kwargs)
 RuntimeError: can't open usrp

 At Tx side -
 r...@gnu2 ofdm]# ./benchmark_ofdm_tx.py -f 25M -i 512 --fft-length=64
 --occupied-tones=32 --cp-length=4
 usrp: failed to find usrp[0]
 Traceback (most recent call last):
  File ./benchmark_ofdm_tx.py, line 217, in module
    main()
  File ./benchmark_ofdm_tx.py, line 190, in main
    tb = my_top_block(options)
  File ./benchmark_ofdm_tx.py, line 51, in __init__
    self._setup_usrp_sink()
  File ./benchmark_ofdm_tx.py, line 66, in _setup_usrp_sink
    fusb_nblocks=self._fusb_nblocks)
  File /usr/local/lib/python2.5/site-packages/gnuradio/usrp/usrp_swig.py,
 line 2415, in sink_c
    return _usrp_swig.sink_c(*args, **kwargs)
 RuntimeError: can't open usrp

 May we request somebody to support us at the earliest to resolve the above
 issue with either software or hardware .

 Thanks again,
 Anupama


This is because you do not have the right permissions set to talk to
the USRP2 as a non-root user. See the USRP2 FAQs on the GNU Radio web
page for how to fix this.

Tom


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

Re: [Discuss-gnuradio] running OFDM on USRP2

[Tom Rondeau]

On Wed, Jan 27, 2010 at 11:21 AM, bin zan zanbin2...@gmail.com wrote:
 Hello,
    I was trying to run following OFDM command on USRP2, however, I got a
 bunch of Stime out at the receiver side.

 ./benchmark_ofdm_tx.py -f 2.4G -i 512 --fft-length=64 --occupied-tones=32
 --cp-length=4
 ./benchmark_ofdm_rx.py -f 2.4G -d 256 --fft-length=64 --occupied-tones=32
 --cp-length=4

 I wonder if there is any one successfully running OFDM on USRP2, what are
 the command parameters you are using and if there is any modification in the
 code, can you let me know.

 Thanks,
 Bin


The 'S' appear because you're missing packets. Using the interpolation
and decimation rates you specified shouldn't be taxi/ng your CPU,
which is a common cause of these problems. Are you running the USRP2
through a switch or is it directly connected?

The time out occurs when the receiver sees the preamble symbol of
the OFDM stream but nothing else. So what is probably happening is
that you get some of the symbols through, including the preamble
symbol, but you're dropping other packets (causing the Ses), which
will trigger the time out message.

Tom


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

Re: [Discuss-gnuradio] running OFDM on USRP2

[Anupama Purohit]

Hi Tom ,
Thanks , we did try the updated script from Veljko . It works though we have
missing packets after a while ( as suggested in the forum we would play with
the interpolation and decimation )  though the 2 USRP2s are directly
connected .

We are still probing into the permissions issue as indicated though we ran
with root permissions
( may be not in totality) , would keep posted on the later if we find
something on the same

Thanks again ,

/Regards

On Wed, Feb 3, 2010 at 8:17 AM, Tom Rondeau trondeau1...@gmail.com wrote:

  On Tue, Feb 2, 2010 at 4:34 PM, Anu000 anupama.puro...@gmail.com wrote:
 
  Hi,
  We did try the below command on two USRP2s coneected via a SMA Cable
 (Tx-Rx)
  with freq = 25M  however it returned the following error on both sides
 
  At Rx side it shows like the below -
 
  [r...@gnuradio1 ofdm]# ./benchmark_ofdm_rx.py -f 25M -d 256
 --fft-length=64
  --occupied-tones=32 --cp-length=4
  usrp: failed to find usrp[0]
  Traceback (most recent call last):
   File ./benchmark_ofdm_rx.py, line 210, in module
 main()
   File ./benchmark_ofdm_rx.py, line 199, in main
 tb = my_top_block(rx_callback, options)
   File ./benchmark_ofdm_rx.py, line 51, in __init__
 self._setup_usrp_source()
   File ./benchmark_ofdm_rx.py, line 70, in _setup_usrp_source
 fusb_nblocks=self._fusb_nblocks)
   File /usr/lib/python2.6/site-packages/gnuradio/usrp/usrp_swig.py, line
  1699, in source_c
 return _usrp_swig.source_c(*args, **kwargs)
  RuntimeError: can't open usrp
 
  At Tx side -
  r...@gnu2 ofdm]# ./benchmark_ofdm_tx.py -f 25M -i 512 --fft-length=64
  --occupied-tones=32 --cp-length=4
  usrp: failed to find usrp[0]
  Traceback (most recent call last):
   File ./benchmark_ofdm_tx.py, line 217, in module
 main()
   File ./benchmark_ofdm_tx.py, line 190, in main
 tb = my_top_block(options)
   File ./benchmark_ofdm_tx.py, line 51, in __init__
 self._setup_usrp_sink()
   File ./benchmark_ofdm_tx.py, line 66, in _setup_usrp_sink
 fusb_nblocks=self._fusb_nblocks)
   File
 /usr/local/lib/python2.5/site-packages/gnuradio/usrp/usrp_swig.py,
  line 2415, in sink_c
 return _usrp_swig.sink_c(*args, **kwargs)
  RuntimeError: can't open usrp
 
  May we request somebody to support us at the earliest to resolve the
 above
  issue with either software or hardware .
 
  Thanks again,
  Anupama


 This is because you do not have the right permissions set to talk to
 the USRP2 as a non-root user. See the USRP2 FAQs on the GNU Radio web
 page for how to fix this.

 Tom




-- 
Thanks  Regards,
Anupama Purohit
972 697 8183 (M)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] running OFDM on USRP2

[bin zan]

Hi Tom,
In our case, even with script from Veljko, the OFDM receiver doesn't show
any thing. And we always see usrp2: failed to enable realtime scheduling.
Do you think that will cause problem?

Thanks,
Bin

On Wed, Feb 3, 2010 at 12:57 PM, Anupama Purohit
anupama.puro...@gmail.comwrote:

 Hi Tom ,
 Thanks , we did try the updated script from Veljko . It works though we
 have missing packets after a while ( as suggested in the forum we would play
 with the interpolation and decimation )  though the 2 USRP2s are directly
 connected .

 We are still probing into the permissions issue as indicated though we ran
 with root permissions
 ( may be not in totality) , would keep posted on the later if we find
 something on the same

 Thanks again ,

 /Regards

 On Wed, Feb 3, 2010 at 8:17 AM, Tom Rondeau trondeau1...@gmail.comwrote:

  On Tue, Feb 2, 2010 at 4:34 PM, Anu000 anupama.puro...@gmail.com
 wrote:
 
  Hi,
  We did try the below command on two USRP2s coneected via a SMA Cable
 (Tx-Rx)
  with freq = 25M  however it returned the following error on both sides
 
  At Rx side it shows like the below -
 
  [r...@gnuradio1 ofdm]# ./benchmark_ofdm_rx.py -f 25M -d 256
 --fft-length=64
  --occupied-tones=32 --cp-length=4
  usrp: failed to find usrp[0]
  Traceback (most recent call last):
   File ./benchmark_ofdm_rx.py, line 210, in module
 main()
   File ./benchmark_ofdm_rx.py, line 199, in main
 tb = my_top_block(rx_callback, options)
   File ./benchmark_ofdm_rx.py, line 51, in __init__
 self._setup_usrp_source()
   File ./benchmark_ofdm_rx.py, line 70, in _setup_usrp_source
 fusb_nblocks=self._fusb_nblocks)
   File /usr/lib/python2.6/site-packages/gnuradio/usrp/usrp_swig.py,
 line
  1699, in source_c
 return _usrp_swig.source_c(*args, **kwargs)
  RuntimeError: can't open usrp
 
  At Tx side -
  r...@gnu2 ofdm]# ./benchmark_ofdm_tx.py -f 25M -i 512 --fft-length=64
  --occupied-tones=32 --cp-length=4
  usrp: failed to find usrp[0]
  Traceback (most recent call last):
   File ./benchmark_ofdm_tx.py, line 217, in module
 main()
   File ./benchmark_ofdm_tx.py, line 190, in main
 tb = my_top_block(options)
   File ./benchmark_ofdm_tx.py, line 51, in __init__
 self._setup_usrp_sink()
   File ./benchmark_ofdm_tx.py, line 66, in _setup_usrp_sink
 fusb_nblocks=self._fusb_nblocks)
   File
 /usr/local/lib/python2.5/site-packages/gnuradio/usrp/usrp_swig.py,
  line 2415, in sink_c
 return _usrp_swig.sink_c(*args, **kwargs)
  RuntimeError: can't open usrp
 
  May we request somebody to support us at the earliest to resolve the
 above
  issue with either software or hardware .
 
  Thanks again,
  Anupama


 This is because you do not have the right permissions set to talk to
 the USRP2 as a non-root user. See the USRP2 FAQs on the GNU Radio web
 page for how to fix this.

 Tom




 --
 Thanks  Regards,
 Anupama Purohit
 972 697 8183 (M)

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


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

Re: [Discuss-gnuradio] running OFDM on USRP2

[Anu000]

Hi,
We did try the below command on two USRP2s coneected via a SMA Cable (Tx-Rx)
with freq = 25M  however it returned the following error on both sides 

At Rx side it shows like the below -

[r...@gnuradio1 ofdm]# ./benchmark_ofdm_rx.py -f 25M -d 256 --fft-length=64
--occupied-tones=32 --cp-length=4
usrp: failed to find usrp[0]
Traceback (most recent call last):
  File ./benchmark_ofdm_rx.py, line 210, in module
main()
  File ./benchmark_ofdm_rx.py, line 199, in main
tb = my_top_block(rx_callback, options)
  File ./benchmark_ofdm_rx.py, line 51, in __init__
self._setup_usrp_source()
  File ./benchmark_ofdm_rx.py, line 70, in _setup_usrp_source
fusb_nblocks=self._fusb_nblocks)
  File /usr/lib/python2.6/site-packages/gnuradio/usrp/usrp_swig.py, line
1699, in source_c
return _usrp_swig.source_c(*args, **kwargs)
RuntimeError: can't open usrp

At Tx side -
r...@gnu2 ofdm]# ./benchmark_ofdm_tx.py -f 25M -i 512 --fft-length=64
--occupied-tones=32 --cp-length=4
usrp: failed to find usrp[0]
Traceback (most recent call last):
  File ./benchmark_ofdm_tx.py, line 217, in module
main()
  File ./benchmark_ofdm_tx.py, line 190, in main
tb = my_top_block(options)
  File ./benchmark_ofdm_tx.py, line 51, in __init__
self._setup_usrp_sink()
  File ./benchmark_ofdm_tx.py, line 66, in _setup_usrp_sink
fusb_nblocks=self._fusb_nblocks)
  File /usr/local/lib/python2.5/site-packages/gnuradio/usrp/usrp_swig.py,
line 2415, in sink_c
return _usrp_swig.sink_c(*args, **kwargs)
RuntimeError: can't open usrp

May we request somebody to support us at the earliest to resolve the above
issue with either software or hardware .

Thanks again,
Anupama



bin zan wrote:
 
 Hello,
I was trying to run following OFDM command on USRP2, however, I got
 a
 bunch of Stime out at the receiver side.
 
 ./benchmark_ofdm_tx.py -f 2.4G -i 512 --fft-length=64 --occupied-tones=32
 --cp-length=4
 ./benchmark_ofdm_rx.py -f 2.4G -d 256 --fft-length=64 --occupied-tones=32
 --cp-length=4
 
 I wonder if there is any one successfully running OFDM on USRP2, what are
 the command parameters you are using and if there is any modification in
 the
 code, can you let me know.
 
 Thanks,
 Bin
 
 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 
 

-- 
View this message in context: 
http://old.nabble.com/running-OFDM-on-USRP2-tp27342376p27427749.html
Sent from the GnuRadio mailing list archive at Nabble.com.



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

RE: [Discuss-gnuradio] running OFDM on USRP2

[Ian Holland]

Hi Anupama

Unfortunately, I can't offer a solution at this stage. However, I had
similar error messages a few days ago. I thought perhaps these python
scripts were to be used exclusively for the original USRPs, though I
think in one or two posts I have seen, people mentioned successfully
running them for USRP2s.

Ian.



-Original Message-
From: discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org
[mailto:discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org] On
Behalf Of Anu000
Sent: Wednesday, 3 February 2010 8:04 AM
To: Discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] running OFDM on USRP2


Hi,
We did try the below command on two USRP2s coneected via a SMA Cable
(Tx-Rx)
with freq = 25M  however it returned the following error on both sides 

At Rx side it shows like the below -

[r...@gnuradio1 ofdm]# ./benchmark_ofdm_rx.py -f 25M -d 256
--fft-length=64
--occupied-tones=32 --cp-length=4
usrp: failed to find usrp[0]
Traceback (most recent call last):
  File ./benchmark_ofdm_rx.py, line 210, in module
main()
  File ./benchmark_ofdm_rx.py, line 199, in main
tb = my_top_block(rx_callback, options)
  File ./benchmark_ofdm_rx.py, line 51, in __init__
self._setup_usrp_source()
  File ./benchmark_ofdm_rx.py, line 70, in _setup_usrp_source
fusb_nblocks=self._fusb_nblocks)
  File /usr/lib/python2.6/site-packages/gnuradio/usrp/usrp_swig.py,
line
1699, in source_c
return _usrp_swig.source_c(*args, **kwargs)
RuntimeError: can't open usrp

At Tx side -
r...@gnu2 ofdm]# ./benchmark_ofdm_tx.py -f 25M -i 512 --fft-length=64
--occupied-tones=32 --cp-length=4
usrp: failed to find usrp[0]
Traceback (most recent call last):
  File ./benchmark_ofdm_tx.py, line 217, in module
main()
  File ./benchmark_ofdm_tx.py, line 190, in main
tb = my_top_block(options)
  File ./benchmark_ofdm_tx.py, line 51, in __init__
self._setup_usrp_sink()
  File ./benchmark_ofdm_tx.py, line 66, in _setup_usrp_sink
fusb_nblocks=self._fusb_nblocks)
  File
/usr/local/lib/python2.5/site-packages/gnuradio/usrp/usrp_swig.py,
line 2415, in sink_c
return _usrp_swig.sink_c(*args, **kwargs)
RuntimeError: can't open usrp

May we request somebody to support us at the earliest to resolve the
above
issue with either software or hardware .

Thanks again,
Anupama



bin zan wrote:
 
 Hello,
I was trying to run following OFDM command on USRP2, however, I
got
 a
 bunch of Stime out at the receiver side.
 
 ./benchmark_ofdm_tx.py -f 2.4G -i 512 --fft-length=64
--occupied-tones=32
 --cp-length=4
 ./benchmark_ofdm_rx.py -f 2.4G -d 256 --fft-length=64
--occupied-tones=32
 --cp-length=4
 
 I wonder if there is any one successfully running OFDM on USRP2, what
are
 the command parameters you are using and if there is any modification
in
 the
 code, can you let me know.
 
 Thanks,
 Bin
 
 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 
 

-- 
View this message in context:
http://old.nabble.com/running-OFDM-on-USRP2-tp27342376p27427749.html
Sent from the GnuRadio mailing list archive at Nabble.com.



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


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

Re: [Discuss-gnuradio] running OFDM on USRP2

[Veljko Pejovic]

Hi,

The example provided with the gnuradio codebase requires small
modifications in order to work with USRP2. You can try with the
modifications I made:

www.cs.ucsb.edu/~veljko/downloads/ofdm_example.tar.gz

In my case with XCVR2450 daughter boards running the following works fine:

transmitter:
benchmark_ofdm_tx_new.py -f 2.45G --tx-amplitude 0.9 -M 8 -s 200 -m
bpsk --fft-length=512 --occupied-tones=80 -i 64 --tx-gain=10
--cp-length=128

receiver:
benchmark_ofdm_rx_new.py -e eth1 -f 2.45G -m bpsk --fft-length=512
--occupied-tones=80 -d 64 --rx-gain=30 --cp-length=128

You can try with the transmitter only first and usrp2_fft.py on the
other end, just to see if there's something getting transmitted and if
it looks like OFDM.

cheers,


veljko

2010/2/2 Ian Holland ian.holl...@rlmgroup.com.au:
 Hi Anupama

 Unfortunately, I can't offer a solution at this stage. However, I had
 similar error messages a few days ago. I thought perhaps these python
 scripts were to be used exclusively for the original USRPs, though I
 think in one or two posts I have seen, people mentioned successfully
 running them for USRP2s.

 Ian.



 -Original Message-
 From: discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org
 [mailto:discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org] On
 Behalf Of Anu000
 Sent: Wednesday, 3 February 2010 8:04 AM
 To: Discuss-gnuradio@gnu.org
 Subject: Re: [Discuss-gnuradio] running OFDM on USRP2


 Hi,
 We did try the below command on two USRP2s coneected via a SMA Cable
 (Tx-Rx)
 with freq = 25M  however it returned the following error on both sides

 At Rx side it shows like the below -

 [r...@gnuradio1 ofdm]# ./benchmark_ofdm_rx.py -f 25M -d 256
 --fft-length=64
 --occupied-tones=32 --cp-length=4
 usrp: failed to find usrp[0]
 Traceback (most recent call last):
  File ./benchmark_ofdm_rx.py, line 210, in module
    main()
  File ./benchmark_ofdm_rx.py, line 199, in main
    tb = my_top_block(rx_callback, options)
  File ./benchmark_ofdm_rx.py, line 51, in __init__
    self._setup_usrp_source()
  File ./benchmark_ofdm_rx.py, line 70, in _setup_usrp_source
    fusb_nblocks=self._fusb_nblocks)
  File /usr/lib/python2.6/site-packages/gnuradio/usrp/usrp_swig.py,
 line
 1699, in source_c
    return _usrp_swig.source_c(*args, **kwargs)
 RuntimeError: can't open usrp

 At Tx side -
 r...@gnu2 ofdm]# ./benchmark_ofdm_tx.py -f 25M -i 512 --fft-length=64
 --occupied-tones=32 --cp-length=4
 usrp: failed to find usrp[0]
 Traceback (most recent call last):
  File ./benchmark_ofdm_tx.py, line 217, in module
    main()
  File ./benchmark_ofdm_tx.py, line 190, in main
    tb = my_top_block(options)
  File ./benchmark_ofdm_tx.py, line 51, in __init__
    self._setup_usrp_sink()
  File ./benchmark_ofdm_tx.py, line 66, in _setup_usrp_sink
    fusb_nblocks=self._fusb_nblocks)
  File
 /usr/local/lib/python2.5/site-packages/gnuradio/usrp/usrp_swig.py,
 line 2415, in sink_c
    return _usrp_swig.sink_c(*args, **kwargs)
 RuntimeError: can't open usrp

 May we request somebody to support us at the earliest to resolve the
 above
 issue with either software or hardware .

 Thanks again,
 Anupama



 bin zan wrote:

 Hello,
        I was trying to run following OFDM command on USRP2, however, I
 got
 a
 bunch of Stime out at the receiver side.

 ./benchmark_ofdm_tx.py -f 2.4G -i 512 --fft-length=64
 --occupied-tones=32
 --cp-length=4
 ./benchmark_ofdm_rx.py -f 2.4G -d 256 --fft-length=64
 --occupied-tones=32
 --cp-length=4

 I wonder if there is any one successfully running OFDM on USRP2, what
 are
 the command parameters you are using and if there is any modification
 in
 the
 code, can you let me know.

 Thanks,
 Bin

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



 --
 View this message in context:
 http://old.nabble.com/running-OFDM-on-USRP2-tp27342376p27427749.html
 Sent from the GnuRadio mailing list archive at Nabble.com.



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


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



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

RE: [Discuss-gnuradio] running OFDM on USRP2

[Ian Holland]

Thanks Veljko

Actually, the problems I had were not with the OFDM case, but just 
benchmark_tx.py and benchmark_rx.py. Are similar modifications necessary for 
those scripts?

Ian.


Hi,

The example provided with the gnuradio codebase requires small
modifications in order to work with USRP2. You can try with the
modifications I made:

www.cs.ucsb.edu/~veljko/downloads/ofdm_example.tar.gz

In my case with XCVR2450 daughter boards running the following works fine:

transmitter:
benchmark_ofdm_tx_new.py -f 2.45G --tx-amplitude 0.9 -M 8 -s 200 -m
bpsk --fft-length=512 --occupied-tones=80 -i 64 --tx-gain=10
--cp-length=128

receiver:
benchmark_ofdm_rx_new.py -e eth1 -f 2.45G -m bpsk --fft-length=512
--occupied-tones=80 -d 64 --rx-gain=30 --cp-length=128

You can try with the transmitter only first and usrp2_fft.py on the
other end, just to see if there's something getting transmitted and if
it looks like OFDM.

cheers,


veljko

2010/2/2 Ian Holland ian.holl...@rlmgroup.com.au:
 Hi Anupama

 Unfortunately, I can't offer a solution at this stage. However, I had
 similar error messages a few days ago. I thought perhaps these python
 scripts were to be used exclusively for the original USRPs, though I
 think in one or two posts I have seen, people mentioned successfully
 running them for USRP2s.

 Ian.



 -Original Message-
 From: discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org
 [mailto:discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org] On
 Behalf Of Anu000
 Sent: Wednesday, 3 February 2010 8:04 AM
 To: Discuss-gnuradio@gnu.org
 Subject: Re: [Discuss-gnuradio] running OFDM on USRP2


 Hi,
 We did try the below command on two USRP2s coneected via a SMA Cable
 (Tx-Rx)
 with freq = 25M  however it returned the following error on both sides

 At Rx side it shows like the below -

 [r...@gnuradio1 ofdm]# ./benchmark_ofdm_rx.py -f 25M -d 256
 --fft-length=64
 --occupied-tones=32 --cp-length=4
 usrp: failed to find usrp[0]
 Traceback (most recent call last):
  File ./benchmark_ofdm_rx.py, line 210, in module
    main()
  File ./benchmark_ofdm_rx.py, line 199, in main
    tb = my_top_block(rx_callback, options)
  File ./benchmark_ofdm_rx.py, line 51, in __init__
    self._setup_usrp_source()
  File ./benchmark_ofdm_rx.py, line 70, in _setup_usrp_source
    fusb_nblocks=self._fusb_nblocks)
  File /usr/lib/python2.6/site-packages/gnuradio/usrp/usrp_swig.py,
 line
 1699, in source_c
    return _usrp_swig.source_c(*args, **kwargs)
 RuntimeError: can't open usrp

 At Tx side -
 r...@gnu2 ofdm]# ./benchmark_ofdm_tx.py -f 25M -i 512 --fft-length=64
 --occupied-tones=32 --cp-length=4
 usrp: failed to find usrp[0]
 Traceback (most recent call last):
  File ./benchmark_ofdm_tx.py, line 217, in module
    main()
  File ./benchmark_ofdm_tx.py, line 190, in main
    tb = my_top_block(options)
  File ./benchmark_ofdm_tx.py, line 51, in __init__
    self._setup_usrp_sink()
  File ./benchmark_ofdm_tx.py, line 66, in _setup_usrp_sink
    fusb_nblocks=self._fusb_nblocks)
  File
 /usr/local/lib/python2.5/site-packages/gnuradio/usrp/usrp_swig.py,
 line 2415, in sink_c
    return _usrp_swig.sink_c(*args, **kwargs)
 RuntimeError: can't open usrp

 May we request somebody to support us at the earliest to resolve the
 above
 issue with either software or hardware .

 Thanks again,
 Anupama



 bin zan wrote:

 Hello,
        I was trying to run following OFDM command on USRP2, however, I
 got
 a
 bunch of Stime out at the receiver side.

 ./benchmark_ofdm_tx.py -f 2.4G -i 512 --fft-length=64
 --occupied-tones=32
 --cp-length=4
 ./benchmark_ofdm_rx.py -f 2.4G -d 256 --fft-length=64
 --occupied-tones=32
 --cp-length=4

 I wonder if there is any one successfully running OFDM on USRP2, what
 are
 the command parameters you are using and if there is any modification
 in
 the
 code, can you let me know.

 Thanks,
 Bin

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



 --
 View this message in context:
 http://old.nabble.com/running-OFDM-on-USRP2-tp27342376p27427749.html
 Sent from the GnuRadio mailing list archive at Nabble.com.



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


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



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

Re: [Discuss-gnuradio] running OFDM on USRP2

[Anupama Purohit]

Hi,
Thanks, we would try the below in our modifications .

however is someone is aware  if the below script works with Basic TX/Basic
Rx Daughter Boards, that would be really helpful



On Tue, Feb 2, 2010 at 5:05 PM, Ian Holland ian.holl...@rlmgroup.com.auwrote:

 Thanks Veljko

 Actually, the problems I had were not with the OFDM case, but just
 benchmark_tx.py and benchmark_rx.py. Are similar modifications necessary for
 those scripts?

 Ian.


 Hi,

 The example provided with the gnuradio codebase requires small
 modifications in order to work with USRP2. You can try with the
 modifications I made:

 www.cs.ucsb.edu/~veljko/downloads/ofdm_example.tar.gz

 In my case with XCVR2450 daughter boards running the following works fine:

 transmitter:
 benchmark_ofdm_tx_new.py -f 2.45G --tx-amplitude 0.9 -M 8 -s 200 -m
 bpsk --fft-length=512 --occupied-tones=80 -i 64 --tx-gain=10
 --cp-length=128

 receiver:
 benchmark_ofdm_rx_new.py -e eth1 -f 2.45G -m bpsk --fft-length=512
 --occupied-tones=80 -d 64 --rx-gain=30 --cp-length=128

 You can try with the transmitter only first and usrp2_fft.py on the
 other end, just to see if there's something getting transmitted and if
 it looks like OFDM.

 cheers,


 veljko

 2010/2/2 Ian Holland ian.holl...@rlmgroup.com.au:
  Hi Anupama
 
  Unfortunately, I can't offer a solution at this stage. However, I had
  similar error messages a few days ago. I thought perhaps these python
  scripts were to be used exclusively for the original USRPs, though I
  think in one or two posts I have seen, people mentioned successfully
  running them for USRP2s.
 
  Ian.
 
 
 
  -Original Message-
  From: discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org
  [mailto:discuss-gnuradio-bounces+ian.hollanddiscuss-gnuradio-bounces%2Bian.holland
 =rlmgroup.com...@gnu.org] On
  Behalf Of Anu000
  Sent: Wednesday, 3 February 2010 8:04 AM
  To: Discuss-gnuradio@gnu.org
  Subject: Re: [Discuss-gnuradio] running OFDM on USRP2
 
 
  Hi,
  We did try the below command on two USRP2s coneected via a SMA Cable
  (Tx-Rx)
  with freq = 25M  however it returned the following error on both sides
 
  At Rx side it shows like the below -
 
  [r...@gnuradio1 ofdm]# ./benchmark_ofdm_rx.py -f 25M -d 256
  --fft-length=64
  --occupied-tones=32 --cp-length=4
  usrp: failed to find usrp[0]
  Traceback (most recent call last):
   File ./benchmark_ofdm_rx.py, line 210, in module
 main()
   File ./benchmark_ofdm_rx.py, line 199, in main
 tb = my_top_block(rx_callback, options)
   File ./benchmark_ofdm_rx.py, line 51, in __init__
 self._setup_usrp_source()
   File ./benchmark_ofdm_rx.py, line 70, in _setup_usrp_source
 fusb_nblocks=self._fusb_nblocks)
   File /usr/lib/python2.6/site-packages/gnuradio/usrp/usrp_swig.py,
  line
  1699, in source_c
 return _usrp_swig.source_c(*args, **kwargs)
  RuntimeError: can't open usrp
 
  At Tx side -
  r...@gnu2 ofdm]# ./benchmark_ofdm_tx.py -f 25M -i 512 --fft-length=64
  --occupied-tones=32 --cp-length=4
  usrp: failed to find usrp[0]
  Traceback (most recent call last):
   File ./benchmark_ofdm_tx.py, line 217, in module
 main()
   File ./benchmark_ofdm_tx.py, line 190, in main
 tb = my_top_block(options)
   File ./benchmark_ofdm_tx.py, line 51, in __init__
 self._setup_usrp_sink()
   File ./benchmark_ofdm_tx.py, line 66, in _setup_usrp_sink
 fusb_nblocks=self._fusb_nblocks)
   File
  /usr/local/lib/python2.5/site-packages/gnuradio/usrp/usrp_swig.py,
  line 2415, in sink_c
 return _usrp_swig.sink_c(*args, **kwargs)
  RuntimeError: can't open usrp
 
  May we request somebody to support us at the earliest to resolve the
  above
  issue with either software or hardware .
 
  Thanks again,
  Anupama
 
 
 
  bin zan wrote:
 
  Hello,
 I was trying to run following OFDM command on USRP2, however, I
  got
  a
  bunch of Stime out at the receiver side.
 
  ./benchmark_ofdm_tx.py -f 2.4G -i 512 --fft-length=64
  --occupied-tones=32
  --cp-length=4
  ./benchmark_ofdm_rx.py -f 2.4G -d 256 --fft-length=64
  --occupied-tones=32
  --cp-length=4
 
  I wonder if there is any one successfully running OFDM on USRP2, what
  are
  the command parameters you are using and if there is any modification
  in
  the
  code, can you let me know.
 
  Thanks,
  Bin
 
  ___
  Discuss-gnuradio mailing list
  Discuss-gnuradio@gnu.org
  http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 
 
 
  --
  View this message in context:
  http://old.nabble.com/running-OFDM-on-USRP2-tp27342376p27427749.html
  Sent from the GnuRadio mailing list archive at Nabble.com.
 
 
 
  ___
  Discuss-gnuradio mailing list
  Discuss-gnuradio@gnu.org
  http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 
 
  ___
  Discuss-gnuradio mailing list
  Discuss-gnuradio@gnu.org
  http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] running OFDM on USRP2

[bin zan]

Hello,
   I was trying to run following OFDM command on USRP2, however, I got a
bunch of Stime out at the receiver side.

./benchmark_ofdm_tx.py -f 2.4G -i 512 --fft-length=64 --occupied-tones=32
--cp-length=4
./benchmark_ofdm_rx.py -f 2.4G -d 256 --fft-length=64 --occupied-tones=32
--cp-length=4

I wonder if there is any one successfully running OFDM on USRP2, what are
the command parameters you are using and if there is any modification in the
code, can you let me know.

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

Re: [Discuss-gnuradio] running OFDM on USRP2

[Veljko Pejovic]

Hi,

I have gnuradio 3.2.2 installed on Ubintu 9.10 and I'm using USRP2s
with XCVR2450 daughterboards.
I tried your example but I changed the interpolation to correspond to
the decimation at the receiver:

./benchmark_ofdm_tx.py -f 2.4G -i 256 --fft-length=64
--occupied-tones=32 --cp-length=4
./benchmark_ofdm_rx.py -f 2.4G -d 256 --fft-length=64
--occupied-tones=32 --cp-length=4

And it works fine.
When I tested the example I played with tx and rx gains and the
tx-amplitude to find the best setting.

Cheers,

Veljko

2010/1/27 bin zan zanbin2...@gmail.com:
 Hello,
    I was trying to run following OFDM command on USRP2, however, I got a
 bunch of Stime out at the receiver side.

 ./benchmark_ofdm_tx.py -f 2.4G -i 512 --fft-length=64 --occupied-tones=32
 --cp-length=4
 ./benchmark_ofdm_rx.py -f 2.4G -d 256 --fft-length=64 --occupied-tones=32
 --cp-length=4

 I wonder if there is any one successfully running OFDM on USRP2, what are
 the command parameters you are using and if there is any modification in the
 code, can you let me know.

 Thanks,
 Bin

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




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

Re: [Discuss-gnuradio] running OFDM on USRP2

[bin zan]

Thanks Veljko, Did you do any modification on the gnuradio 3.2.2 code?
(Because at my side the interpolation/decimation was not the problem, I
forgot to change the value in the email)

Bin


On Wed, Jan 27, 2010 at 2:44 PM, Veljko Pejovic vel...@cs.ucsb.edu wrote:

 Hi,

 I have gnuradio 3.2.2 installed on Ubintu 9.10 and I'm using USRP2s
 with XCVR2450 daughterboards.
 I tried your example but I changed the interpolation to correspond to
 the decimation at the receiver:

 ./benchmark_ofdm_tx.py -f 2.4G -i 256 --fft-length=64
 --occupied-tones=32 --cp-length=4
 ./benchmark_ofdm_rx.py -f 2.4G -d 256 --fft-length=64
 --occupied-tones=32 --cp-length=4

 And it works fine.
 When I tested the example I played with tx and rx gains and the
 tx-amplitude to find the best setting.

 Cheers,

 Veljko

 2010/1/27 bin zan zanbin2...@gmail.com:
  Hello,
 I was trying to run following OFDM command on USRP2, however, I
 got a
  bunch of Stime out at the receiver side.
 
  ./benchmark_ofdm_tx.py -f 2.4G -i 512 --fft-length=64 --occupied-tones=32
  --cp-length=4
  ./benchmark_ofdm_rx.py -f 2.4G -d 256 --fft-length=64 --occupied-tones=32
  --cp-length=4
 
  I wonder if there is any one successfully running OFDM on USRP2, what are
  the command parameters you are using and if there is any modification in
 the
  code, can you let me know.
 
  Thanks,
  Bin
 
  ___
  Discuss-gnuradio mailing list
  Discuss-gnuradio@gnu.org
  http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 
 

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

[Discuss-gnuradio] running ofdm benchmark on XCVR2450 vs RFX2400

[Apurv Bhartia]

Hey -

This is a strange thing that I've been facing. We recently purchased new
XCVR2450 daughterboards and wanted to test the ofdm benchmark code on it
(with default settings). Both the USRPs (USRP1), were almost next to each
other but yet, the receiver USRP does not show any packets being received.
This is strange, since I plugged in a spectrum analyzer next to it, and it
shows that the signal is indeed transmitted. I believe there's some issue
with the rate at which the transmission takes place. I decreased the
decimation rate to 4 on receiver and as expect it indicates overrun.
However, when I increase it beyond 16, all I get are TIMEOUTs.

At the sender, the interpolation rate is 128. I tried playing with some
other values but couldn't get the reception to take place at the receiver.

What is incredibly surprising is this - if I plug in the RFX2400 boards
instead of these, they work with the default settings, except that I have to
increase the tx-amplitude. I'm totally stumped at this behavior.

The machines are not loaded at all, there's just the USRPs running (Ubuntu
9.04, 2.6GHz). I also checked the /proc/cpuinfo to verify, and it seems that
the clock speed is fine.

I'd appreciate any help. I thought the changeover from RFX2400 to XCVR2450
would be smooth, but its giving me a bit of a nightmare. Btw, I'm running a
stable 3.2.2 release of gnuradio.

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

[Discuss-gnuradio] running python tests

[DJamel H. Sadok]

Dear all,

I just installed gnuradio and a USRP. When running the python tests such 
as the one bellow I am getting the following error message that seems to 
do with some upgrade:


test_dft_synth.py  usrp_tv_rcv.py
%: ~/gnuradio-3.1.3/gnuradio-examples/python/usrp$ 
./test_dft_analysis.py

Traceback (most recent call last):
  File ./test_dft_analysis.py, line 4, in module
from gnuradio.wxgui import stdgui2, fftsink2, slider
ImportError: cannot import name stdgui2

Could anyone help?

Thanks, Djamel



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

Re: [Discuss-gnuradio] Running usrp2_wfm_rcv.py

[Catalin Lacatus]

Hello,

I attached the results of svn info for:

gnuradio
usrp2_wfm_rcv.py
usrp2_fft.py

The reversions are below.


gnuradio

Repository Root: http://gnuradio.org/svn

Repository UUID: 221aa14e-8319-0410-a670-987f0aec2ac5

Revision: 9900

Node Kind: directory

Schedule: normal

Last Changed Author: jcorgan

Last Changed Rev: 9863

Last Changed Date: 2008-10-26 23:09:27 -0400 (Sun, 26 Oct 2008)


usrp2_wfm_rcv.py

[EMAIL PROTECTED]:/home/gnuradio/gnuradio# svn info

Path: .

URL: http://gnuradio.org/svn/gnuradio/trunk

Repository Root: http://gnuradio.org/svn

Repository UUID: 221aa14e-8319-0410-a670-987f0aec2ac5

Revision: 9900

Node Kind: directory

Schedule: normal

Last Changed Author: eb

Last Changed Rev: 9878

Last Changed Date: 2008-10-27 12:36:52 -0400 (Mon, 27 Oct 2008)



usrp2_fft.py

[EMAIL PROTECTED]:/home/gnuradio/gnuradio/gr-utils/src/python# svn info

Path: .

URL: http://gnuradio.org/svn/gnuradio/trunk/gr-utils/src/python

Repository Root: http://gnuradio.org/svn

Repository UUID: 221aa14e-8319-0410-a670-987f0aec2ac5

Revision: 9900

Node Kind: directory

Schedule: normal

Last Changed Author: jcorgan

Last Changed Rev: 9864

Last Changed Date: 2008-10-26 23:32:36 -0400 (Sun, 26 Oct 2008)


Please let me know how I can solve this problem.

Thank you,

Catalin

Johnathan Corgan wrote:

On Thu, Nov 13, 2008 at 5:48 AM, Catalin LACATUS
[EMAIL PROTECTED] wrote:

  

-I tried to run usrp2_wfm_rcv.py to test my USRP2 with a BasicRX board and I
got the following error.
¨AttributeError: 'usrp2_source_32fc_sptr' object has no attribute
'adc_rate'¨



Could you please confirm which repository revision of software you are
using?  Change into the top level directory that you checked out the
source code into, and type:

$ svn info

On the surface, this looks like a version mismatch between the
usrp2_fft.py script and the rest of GNU Radio.  It could be other
things as well, however.

-Johnathan
  




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

Re: [Discuss-gnuradio] Running usrp2_wfm_rcv.py

[Johnathan Corgan]

On Fri, Nov 14, 2008 at 7:53 AM, Catalin Lacatus
[EMAIL PROTECTED] wrote:

 I attached the results of svn info for:

Thanks.  While it looks like your repository is in order, the version
of the Python script you are running doesn't appear to match the
version of the USRP2 library that is actually installed on the system.

Other people who have recently reported similar issues as you have
solved it by doing a fresh rebuild and reinstallation of the code.
You can do this either by checking out a fresh version of the trunk,
or, by running 'make distclean', then repeating the usual steps for
configuration and installation.

-Johnathan


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

RE: [Discuss-gnuradio] Running usrp2_wfm_rcv.py

[Newman, Timothy]

For both those functions you need to pass in the variable you want assigned the 
value as an input parameter.

 

Look at gnuradio/trunk/gr-usrp2/src/usrp2_source_base.cc for the function 
definitions of adc_rate and daughterboard_id.

 

Tim

 

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Catalin LACATUS
Sent: Thursday, November 13, 2008 8:48 AM
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] Running usrp2_wfm_rcv.py

 

Hello,

-I tried to run usrp2_wfm_rcv.py to test my USRP2 with a BasicRX board and I 
got the following error.
¨AttributeError: 'usrp2_source_32fc_sptr' object has no attribute 'adc_rate'¨

 

-After I set the adc_rate=100e6, I got the following error:

 

AttributeError: 'usrp2_source_32fc_sptr' object has no attribute 
'daughterboard_id' 

-Testing ./find-usrps script is running fine with following result.
00:50:c2:85:30:0a hw_rev = 0x0300

My configuration is
-Ubuntu 8.04, with the latest svn (7 days old)-USRP2 with a BasicRX
- I am using Netgear Gigabit switch to connect to fast Ethernet port on my 
laptop. I could not directly connect my Gigabit PCMCIA card to USRP2. 

Please let me know how I can fix the error AttributeError: 
'usrp2_source_32fc_sptr' object has no attribute 'daughterboard_id' 

Thank you,
-Catalin 

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

Re: [Discuss-gnuradio] Running usrp2_wfm_rcv.py

[Johnathan Corgan]

On Thu, 2008-11-13 at 08:48 -0500, Catalin LACATUS wrote:

 -I tried to run usrp2_wfm_rcv.py to test my USRP2 with a BasicRX board
 and I got the following error.
 ¨AttributeError: 'usrp2_source_32fc_sptr' object has no attribute
 'adc_rate'¨

This likely a bug in the host driver for the USRP2; I will work on this
today.

-Johnathan



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

RE: [Discuss-gnuradio] Running usrp2_wfm_rcv.py

[Johnathan Corgan]

On Thu, 2008-11-13 at 10:12 -0500, Newman, Timothy wrote:
 For both those functions you need to pass in the variable you want
 assigned the value as an input parameter.
 
  
 
 Look at gnuradio/trunk/gr-usrp2/src/usrp2_source_base.cc for the
 function definitions of adc_rate and daughterboard_id.

Actually, that is correct for the C++ API, but for Python we add a small
shim to make it return the value instead of passing a pointer into it.
So the code in usrp2_fft.py is calling it correctly.

-Johnathan





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

Re: [Discuss-gnuradio] Running usrp2_wfm_rcv.py

[Johnathan Corgan]

On Thu, Nov 13, 2008 at 5:48 AM, Catalin LACATUS
[EMAIL PROTECTED] wrote:

 -I tried to run usrp2_wfm_rcv.py to test my USRP2 with a BasicRX board and I
 got the following error.
 ¨AttributeError: 'usrp2_source_32fc_sptr' object has no attribute
 'adc_rate'¨

Could you please confirm which repository revision of software you are
using?  Change into the top level directory that you checked out the
source code into, and type:

$ svn info

On the surface, this looks like a version mismatch between the
usrp2_fft.py script and the rest of GNU Radio.  It could be other
things as well, however.

-Johnathan


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

Re: [Discuss-gnuradio] Running OFDM files

[Tom Rondeau]

Jose Emilio Gervilla Rega wrote:

Hello all,

I will give you more details about my problem because someone has 
asked me for them(thank you):


The OFDM system we are using is which is defined in this link:

http://gnuradio.org/trac/browser/gnuradio/branches/developers/n4hy/ofdm/gnuradio-core/src/python/gnuradio/blksimpl?rev=5763

The file ofdm.py is the transmitter and the other ones are receiver 
and synchronization modules. When I run ofdm.py which I've copied into 
the folder I told you on the other topic(the first one), appear some 
errors. If I type ./ofdm.py the output is:


./ofdm.py: line 23: import: order not found
from: can't read /var/mail/numpy
from: can't read /var/mail/gnuradio
./ofdm.py: line 26: import: order not found
from: can't read /var/mail/gnuradio.blksimpl.ofdm_receiver
./ofdm.py: line 35: sintax error near token no hoped `('
./ofdm.py: line 35: `class ofdm_mod(gr.hier_block):'


I'm using Linux Ubuntu 7.04 and gnuradio 3.1.1.

Thank you all for help us!!


Jose,

You are not quite using those blocks correctly, anyway. They depend on 
their location to be properly imported. All of the core OFDM blocks are 
locaked in blks2impl and can be imported using gnuradio.blks2:


from gnuradio import gr, blks2

Then you can access blks2.ofdm or blks2.ofdm_receiver.

If you are working on a new type of synchronization, you'll want to 
place that in blks2impl. You'll find there are already four different 
types already there: ofdm_sync_pn, ofdm_sync_pnac, ofdm_sync_ml, and 
ofdm_sync_fixed. The fixed version simply knows how long to delay the 
triggering and assumes no frequency offset and was used just to test the 
mod/demod blocks. Of the rest, only the PN sequence synchronization 
currently works (and may be the only one that will ever work of these).


I think a bit of reorganization is due for the sync blocks, anyway. They 
do 1 or 2 steps too many. I would like to remove the ofdm_sampler from 
it, put that block in ofdm_receiver and output two streams from each 
sync: a timing trigger for when the preamble is detected and the fine 
frequency derotated OFDM symbol. The idea being a general interface for 
different OFDM sync blocks like yours that we could fit in.


Make sense?

Tom




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

[Discuss-gnuradio] Running OFDM files

[Jose Emilio Gervilla Rega]

Hello all,
 
We are working in OFDM synchronization. When you install GNURadio, there are 
among the examples an OFDM system which runs perfectly. But we need to run 
other different files that we have found in GNURadio website where uses some 
different kinds of synchronization in order to include our synchronization in 
this system. The problem is that we have downloaded these files, we have copied 
them into the folder gnuradio-examples/python/ofdm and we have tried to run 
this system but it doesn´t. There are several errors saying that import is 
not a known command or something similar. We suppose that what we have 
downloaded is coded ok because it is in the website and the errors are really 
strange because import is a well-known python command, and that our problem 
is because we have copied it in the wrong folder or something like this.
 
Does anyone could help us to get to run it?
 
Thank you!
_
MSN Video. 
http://video.msn.com/?mkt=es-es___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Running OFDM files

[Brian Padalino]

On Wed, Feb 27, 2008 at 9:18 AM, Jose Emilio Gervilla Rega
[EMAIL PROTECTED] wrote:

  Hello all,

  We are working in OFDM synchronization. When you install GNURadio, there
 are among the examples an OFDM system which runs perfectly. But we need to
 run other different files that we have found in GNURadio website where uses
 some different kinds of synchronization in order to include our
 synchronization in this system. The problem is that we have downloaded these
 files, we have copied them into the folder gnuradio-examples/python/ofdm and
 we have tried to run this system but it doesn´t. There are several errors
 saying that import is not a known command or something similar. We suppose
 that what we have downloaded is coded ok because it is in the website and
 the errors are really strange because import is a well-known python
 command, and that our problem is because we have copied it in the wrong
 folder or something like this.

  Does anyone could help us to get to run it?

A few things would be more helpful:

1. A link to the code you think should be working (please don't attach
and post to the list)
2. The version of GNU Radio you are working with
3. Your system configuration (OS, architecture, etc, etc)
4. The command you're running and the erroneous output

These types of things are always required or else you may not get many
responses since your errors are too vague.

Brian


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

Re: [Discuss-gnuradio] Running OFDM files

[Brian Padalino]

On Wed, Feb 27, 2008 at 11:43 AM, Jose Emilio Gervilla Rega
[EMAIL PROTECTED] wrote:

  Hello all,

 I will give you more details about my problem because someone has asked me
 for them(thank you):

 The OFDM system we are using is which is defined in this link:

 http://gnuradio.org/trac/browser/gnuradio/branches/developers/n4hy/ofdm/gnuradio-core/src/python/gnuradio/blksimpl?rev=5763

 The file ofdm.py is the transmitter and the other ones are receiver and
 synchronization modules. When I run ofdm.py which I've copied into the
 folder I told you on the other topic(the first one), appear some errors. If
 I type ./ofdm.py the output is:

 ./ofdm.py: line 23: import: order not found
 from: can't read /var/mail/numpy
 from: can't read /var/mail/gnuradio
 ./ofdm.py: line 26: import: order not found
 from: can't read /var/mail/gnuradio.blksimpl.ofdm_receiver
 ./ofdm.py: line 35: sintax error near token no hoped `('
 ./ofdm.py: line 35: `class ofdm_mod(gr.hier_block):'

I don't think those files are for running from the shell.

For OFDM examples, why not check out:


http://gnuradio.org/trac/browser/gnuradio/trunk/gnuradio-examples/python/ofdm?rev=5763

They should be installed on your local system here:

/usr/local/share/gnuradio/examples/ofdm

You might have better success checking out those, especially the
benchmark scripts.

Brian


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

Re: [Discuss-gnuradio] running a gmsk test

[George Nychis]

Eric Blossom wrote:

George,

See gnuradio-examples/python/digital/benchmark_loopback.py

Try the --help option.

To select gmsk, use -m gmsk

Eric



Just to follow up on this in case anyone wanted to use the original test 
script for anything, the parameters to setting up the GMSK modulation 
and demodulation have changed.  So, modify the lines which call 
gmsk_mod() and gmsk_demod() to have proper parameters.


- George


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

[Discuss-gnuradio] running a gmsk test

[George Nychis]

I'm not sure where the gmsk test went in GNU Radio, I tried following 
the log and commits.  So, I grabbed a gmsk test from here:

http://noether.uoregon.edu/~jl/gmsk/

Just trying to run something simple, I run it from the blksimpl 
directory like this:
[EMAIL PROTECTED]:~/school/gr/gmsk/gnuradio-core/src/python/gnuradio/blksimpl$ 
./gmsk-test.py -f payload.dat

sps:8
symbol_rate:270833.33
sample_rate:216.7
p_size: 1024
 gr_fir_fff: using SSE
bits per symbol = 1
Gaussian filter bt = 270833.33
Modulation logging turned on.
python: gri_mmse_fir_interpolator.cc:67: float 
gri_mmse_fir_interpolator::interpolate(const float*, float) const: 
Assertion `imu = NSTEPS' failed.


Given that the test program is two years old now, I'm sure something has 
changed.  But does an up to date gmsk test program still exist that does 
not need the USRP?  I found the DECT example, but that's USRP based.


Thanks!
George


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