[Discuss-gnuradio] duration of uhd_rx_cfile script

[Sebastian Döring]

Hello all,

I just measured the time the execution of uhd_rx_cfile.py 
takes all together.
I used N=2, samp-rate=1M and the rest was left to the 
default values.


In theory the taking of the samples should take T=N/B=20ms 
but I had to discover that the whole process is taking 
about 2s.


Does anybody know what exactly is taking so long and if 
there is a way to speed it up?
Since I am actually planning to somehow use this script 
(or parts of it) in the context of spectrum 
sensing/monitoring for dynamic access, 2 seconds is 
definitely taking to long.



Thanks in advance.

Sebastian

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

Re: [Discuss-gnuradio] duration of uhd_rx_cfile script

[Marcus D. Leech]

On 14/12/11 03:21 AM, Sebastian Döring wrote:
> Hello all,
>
> I just measured the time the execution of uhd_rx_cfile.py takes all
> together.
> I used N=2, samp-rate=1M and the rest was left to the default values.
>
> In theory the taking of the samples should take T=N/B=20ms but I had
> to discover that the whole process is taking about 2s.
>
> Does anybody know what exactly is taking so long and if there is a way
> to speed it up?
> Since I am actually planning to somehow use this script (or parts of
> it) in the context of spectrum sensing/monitoring for dynamic access,
> 2 seconds is definitely taking to long.
>
>
> Thanks in advance.
>
> Sebastian
>
> ___
>
Well, there's loading the Python interpreter, and the shared libraries
it immediately relies on.  Then
  there's loading all of the gnuradio and other "stuff" that is
"imported" into your running Python image.
  Then there's creating and starting the flow-graph.  Then there's the
setting-up of the hardware that
  UHD has to do on startup.  Yup, I can see that taking 2 seconds or more.

If what you want to do is "set frequency, record some data for awhile,
change to a new frequency,
  rinse, repeat", then you're better off writing a custom flow-graph
that does that, rather than trying
  to "script" something like uhd_rx_file.py.  Once a flow-graph is setup
and created, the overhead drops
  quite a bit.

I think: gnuradio/gr-uhd/examples/usrp_spectrum_sense.py

Already does a lot of what you want.




-- 
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] duration of uhd_rx_cfile script

[Sebastian Döring]

On Wed, 14 Dec 2011 07:36:38 -0500
 "Marcus D. Leech"  wrote:

On 14/12/11 03:21 AM, Sebastian Döring wrote:

Hello all,

I just measured the time the execution of 
uhd_rx_cfile.py takes all

together.
I used N=2, samp-rate=1M and the rest was left to 
the default values.


In theory the taking of the samples should take 
T=N/B=20ms but I had

to discover that the whole process is taking about 2s.

Does anybody know what exactly is taking so long and if 
there is a way

to speed it up?
Since I am actually planning to somehow use this script 
(or parts of
it) in the context of spectrum sensing/monitoring for 
dynamic access,

2 seconds is definitely taking to long.


Thanks in advance.

Sebastian

___

Well, there's loading the Python interpreter, and the 
shared libraries

it immediately relies on.  Then
 there's loading all of the gnuradio and other "stuff" 
that is

"imported" into your running Python image.
 Then there's creating and starting the flow-graph. 
Then there's the

setting-up of the hardware that
 UHD has to do on startup.  Yup, I can see that taking 2 
seconds or more.


If what you want to do is "set frequency, record some 
data for awhile,

change to a new frequency,
 rinse, repeat", then you're better off writing a custom 
flow-graph

that does that, rather than trying
 to "script" something like uhd_rx_file.py.  Once a 
flow-graph is setup

and created, the overhead drops
 quite a bit.

I think: gnuradio/gr-uhd/examples/usrp_spectrum_sense.py

Already does a lot of what you want.




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


Thanks a lot. Code really looks like what I am looking 
for.
Concerning the machine+Python version combinations that 
cause seg faults: Is there a known combination that works?

Seems like mine doesn't.

-Sebastian

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

Re: [Discuss-gnuradio] duration of uhd_rx_cfile script

[Marcus D. Leech]

On 14/12/11 08:05 AM, Sebastian Döring wrote:
>
> Thanks a lot. Code really looks like what I am looking for.
> Concerning the machine+Python version combinations that cause seg
> faults: Is there a known combination that works?
> Seems like mine doesn't.
>
> -Sebastian
>
>
Could you expand on that a bit, please?  Perhaps with an error log, and
what you were trying to do when
  you got a segfault?



-- 
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] Importing Grblock or not?

[Urban Kuhar]

Hi guys!

I have problems with writing a processing block in python. I looked at the
examples here
http://gnuradio.org/redmine/projects/gnuradio/wiki/WriteBlocksInPython but
when I try to create a new class that inherits gr.sync_block (or any other
from the example) I get this output:

Traceback (most recent call last):
  File "./python_processing_block", line 27, in 
class add_2_f32_1_f32(gr.sync_block):
AttributeError: 'module' object has no attribute 'sync_block'

I wrote the signal processing block in C++ where I created a class that
inherits gr_block and it work fine. Is there some module that I should
import or am I missing something else?

Best regards,
Urban Kuhar

On Tue, Nov 29, 2011 at 12:34 AM, Alex Zhang wrote:

> With 90% possibility, my building issue of boost is caused by the conflict
> between the built-in boost library and the post installed boost libs.
> After removing all the libboost* in the /usr/lib/ and changing
> environmental value LD_LIBRARY_PATH by delete the path to my self-installed
> boost directory, I re-installed the boost by
> sudo apt-get install libboost-dev libboost-doc
> Now the next branch can be build successfully.
>
> On Wed, Nov 23, 2011 at 9:44 AM, Josh Blum  wrote:
>
>>
>>
>> > If I build and install the gnuradio based on your next branch, do we
>> still
>> > need use "import grblock" in the application code?
>> >
>>
>> No, the old module "grblock" is gone, the work is now integrated into
>> "gnuradio.gr". Did you see the examples here:
>>
>> http://gnuradio.org/redmine/projects/gnuradio/wiki/WriteBlocksInPython#Some-quick-examples
>>
>> If you solve your build issue with boost, please let me know. I am
>> interested to understand the cause.
>>
>> -Josh
>>
>
>
>
> --
>
> Alex,
> *Dreams can come true – just believe.*
>
>
> ___
> 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] Importing Grblock or not?

[Josh Blum]

On 12/14/2011 08:07 AM, Urban Kuhar wrote:
> Hi guys!
> 
> I have problems with writing a processing block in python. I looked at the
> examples here
> http://gnuradio.org/redmine/projects/gnuradio/wiki/WriteBlocksInPython but
> when I try to create a new class that inherits gr.sync_block (or any other
> from the example) I get this output:
> 
> Traceback (most recent call last):
>   File "./python_processing_block", line 27, in 
> class add_2_f32_1_f32(gr.sync_block):
> AttributeError: 'module' object has no attribute 'sync_block'
> 
> I wrote the signal processing block in C++ where I created a class that
> inherits gr_block and it work fine. Is there some module that I should
> import or am I missing something else?
> 

This feature is not in mainline. Its part of my next branch. I also
squashed the work (without message passing) into python_blocks branch.
http://gnuradio.org/cgit/jblum.git

-Josh

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

[Discuss-gnuradio] UHD Calibration continued.

[Evan Merewether]

I have been looking more at the performance of the udh_cal_* routines to try
and understand the operation of my N210 and the SBX card.  I found the cal
files that I had previously generated and moved them into a separate
directory to prevent the UHD driver from finding them.  From the
documentation, I think this should apply no corrections.  Then I removed the
antennas and terminated both inputs with 50 ohm terminators, running
uhd_fft.grc with a frequency of 2.0087MHz (which is away from other spurious
signals and near a calibration point), a sampling rate at 5M, a 2.048k FFT
size, and an average of 0.004 produces a graph where I can observe both the
average leakage power of the LO and the average noise floor.  This produced
data for the LO [A - -99.21 dB, FFT: -106.14 dB] and noise [A: -117.138,
FFT: -117.1 dB].

 

I then ran uhd_rx_iq_balance which produced the file
/home/gnube/.uhd/cal/rx_iq_cal_v0.1_E2R12X1XS.csv.  

With correction line of 2.0087e+09, 0.961492, -0.307198, 76.7275, 38.7414 

Running uhd_fft.grc again produced no change to the measurements.

 

I then ran uhd_tx_iq_balance which produced the file
/home/gnube/.uhd/cal/tx_iq_cal_v0.1_E2R12X1XS.csv.

With correction line of 2.0087e+09, 0.962229, 0.0709783, 77.7254, 39.0847   

Running uhd_fft.grc again produced no change to the measurements.

 

I then ran uhd_tx_dc_offset which produced the file
/home/gnube/.uhd/cal/tx_dc_cal_v0.1_E2R12X1XS.csv.

With correction line of 2.0087e+09, -0.0108594, -0.00078125, -95.2992,
51.6633

Running uhd_fft.grc again produced no change to the measurements.

 

Can anyone tell me what mistake I am making?

 

Evan Merewether

 

 

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

Re: [Discuss-gnuradio] Question about benchmark_tx and benchmark_rx

[محمد روسلي]

Hi there,

I made some decent progress but refining the parameters for the
benchmark_tx.py and benchmark_rx.py without no errors. However, I can only
transmit but I could not receive anything at the receiver side. Could
somebody suggest what might be the problem? I tried to work it but still
could not find answer on why I did not received anything.

Used code:

./benchmark_tx.py -f 400M -r 250k -S 4

and

./benchmark_rx.py -f 400M -r 250k -S 4

OS: Ubuntu 11.10 (which I read in blog said that it has some problem with
gnuradio)
Gnuradio: 3.5.0 rc 0 (which I git from master branch)
Hardware: USRP1(transmitter), USRP N210(receiver)
Machine: Lenovo T510 (transmitter), Dell Desktop

Regards,
Muhammad

On Thu, Dec 8, 2011 at 11:09 AM, Muhammad Rosli wrote:

> Hi,
>
> I am using:
> OS: Ubuntu 11.10 (which I read in blog said that it has some problem with
> gnuradio)
> Gnuradio: 3.5.0 rc 0 (which I git from master branch)
>
> I quite puzzled it's not working with my current setup. It seems doable by
> many people but not me.
>
>
> Regards,
> Muhammad b Rosli
> Student
> Bachelor of Electrical and Electronic
> University of Canterbury
>
>
> On Wed, Dec 7, 2011 at 12:14 PM, Tom Rondeau wrote:
>
>> On Thu, Dec 1, 2011 at 10:15 PM, Muhammad Rosli wrote:
>>
>>> Hi,
>>>
>>> Thanks for your reply. I am using the narrowband example.
>>>
>>> If I attempt using
>>>
>>> ./benchmark_tx.py -f 400M -r 250k -S 4
>>>
>>> and
>>>
>>> ./benchmark_rx.py -f 400M -r 250k -S 4
>>>
>>> which I worked out from reading the README file, the receiver still
>>> output overrun (many '0'). I verified that the transmitter working since my
>>> spectrum analyser can pickup the signal from the transmitter.
>>>
>>>
>>> --
>>> Regards,
>>> Muhammad b Rosli
>>> Student
>>> Bachelor of Electrical and Electronic
>>> University of Canterbury
>>>
>>
>>
>> What is your OS, version of GNU Radio, hardware?
>>
>> By default, the digital benchmarks run GMSK, so that with 250 kbps rate
>> should be easily doable without overruns on most modern machines.
>>
>> Tom
>>
>>
>>
>>>
>>>  On Fri, Dec 2, 2011 at 3:56 PM, Marcus D. Leech wrote:
>>>
 **
 On 12/01/2011 09:36 PM, Muhammad Rosli wrote:

 Hi,

 Thanks for reading my mail. I would like to ask is there any additional
 setup or configuration required to execute benchmark_tx.py and
 benchmark_rx.py?

 My problem is I tried to initiate simple communication between two
 USRP1 using benchmark_rx.py and benchmark_tx.py . I had browse through the
 mailing list looking on how to use the file appropriately. Running
 benchmark_tx.py also execute help which I follow closely but failed to
 receive any packets. If I tried to execute at transmitter:

 benchmark_tx.py -f 400M -S 10

 and at receiver

 benchmark_rx.py -f 400M -S 10

 I did not received packet status. I only received '0' in the terminal.
 Is it correspond to error?

 I also read mailing list sent by other members but none mentioned about
 not able to execute benchmark_tx.py . If I missed any post, could anyone
 please provide me the link.

 For additional information:
 Gnuradio version used: v3.5.0rc0
 USRP1 : revision 4
 Ubuntu: 11.10
 Daugtherboard: SBX

 Please let me know if I had to provide any additional information.

 --
 Regards,
 Muhammad b Rosli
 Student
 Bachelor of Electrical and Electronic
 University of Canterbury

  You're asking for 10 samples per symbol, which may exceed the rate at
 which your receiver computer can keep up, depending on
   the modulation used, and the complexity of the modulation
 techniques.  Are you using the narrowband or ofdm examples?

 The 'O' means overrun.  The hardware (USRP1) is sending samples faster
 than your computer can keep up.




 --
 Marcus Leech
 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
>>>
>>>
>>
>
>
> --
> Regards,
> Muhammad b Rosli
> Student
> Bachelor of Electrical and Electronic
> University of Canterbury
>
>


-- 
Regards,
Muhammad b Rosli
Student
Bachelor of Electrical and Electronic
University of Canterbury
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] UHD Calibration continued.

[Josh Blum]

On 12/14/2011 01:55 PM, Evan Merewether wrote:
> I have been looking more at the performance of the udh_cal_* routines to try
> and understand the operation of my N210 and the SBX card.  I found the cal
> files that I had previously generated and moved them into a separate
> directory to prevent the UHD driver from finding them.  From the
> documentation, I think this should apply no corrections.  Then I removed the

correct

> antennas and terminated both inputs with 50 ohm terminators, running
> uhd_fft.grc with a frequency of 2.0087MHz (which is away from other spurious
> signals and near a calibration point), a sampling rate at 5M, a 2.048k FFT
> size, and an average of 0.004 produces a graph where I can observe both the
> average leakage power of the LO and the average noise floor.  This produced
> data for the LO [A - -99.21 dB, FFT: -106.14 dB] and noise [A: -117.138,
> FFT: -117.1 dB].
> 

So you are measuring the transmit LO leaking into receive? Which means
uhd_fft.grc is both transmitting and receiving?

> Can anyone tell me what mistake I am making?
> 
>  

The cal utilities are for suppressing IQ imbalance on RX and TX and DC
level on transmit. I dont know exactly what uhd_fft.grc is, but I dont
think you are measuring IQ suppression or TX DC level.

-Josh

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

Re: [Discuss-gnuradio] Question about benchmark_tx and benchmark_rx

[Marcus D. Leech]

Hi there,

I made some decent progress but refining the parameters for the 
benchmark_tx.py and benchmark_rx.py without no errors. However, I can 
only transmit but I could not receive anything at the receiver side. 
Could somebody suggest what might be the problem? I tried to work it 
but still could not find answer on why I did not received anything.


Used code:

./benchmark_tx.py -f 400M -r 250k -S 4

and

./benchmark_rx.py -f 400M -r 250k -S 4

OS: Ubuntu 11.10 (which I read in blog said that it has some problem 
with gnuradio)

Gnuradio: 3.5.0 rc 0 (which I git from master branch)
Hardware: USRP1(transmitter), USRP N210(receiver)
Machine: Lenovo T510 (transmitter), Dell Desktop

Regards,
Muhammad

A common reason for this type of problem is frequency-offset between RX 
and TX.  On the RX side, use uhd_fft.py to observe the spectrum
  and see where the receiver thinks the peak of the spectrum is.  Then 
adjust your '-f' accordingly on a subsequent run of benchmark_rx.py.


Crystal oscillators aren't perfect.  Even an error of a few 10s of PPM 
can add up to several Khz at center frequencies in the hundreds of
  MHz.  Unless the receive flow-graph has a way of correcting gross 
frequency error, you will have to do that manually.


This is such a common problem that I'm surprised you haven't covered it 
in your coursework yet.  Real radios (and radio channels) have

  impairments that often aren't adequately modelled by simulations.

--
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] Question about benchmark_tx and benchmark_rx

[Tom Rondeau]

On Wed, Dec 14, 2011 at 7:24 PM, Marcus D. Leech  wrote:

>  Hi there,
>>
>> I made some decent progress but refining the parameters for the
>> benchmark_tx.py and benchmark_rx.py without no errors. However, I can only
>> transmit but I could not receive anything at the receiver side. Could
>> somebody suggest what might be the problem? I tried to work it but still
>> could not find answer on why I did not received anything.
>>
>> Used code:
>>
>> ./benchmark_tx.py -f 400M -r 250k -S 4
>>
>> and
>>
>> ./benchmark_rx.py -f 400M -r 250k -S 4
>>
>> OS: Ubuntu 11.10 (which I read in blog said that it has some problem with
>> gnuradio)
>> Gnuradio: 3.5.0 rc 0 (which I git from master branch)
>> Hardware: USRP1(transmitter), USRP N210(receiver)
>> Machine: Lenovo T510 (transmitter), Dell Desktop
>>
>> Regards,
>> Muhammad
>>
>>  A common reason for this type of problem is frequency-offset between RX
> and TX.  On the RX side, use uhd_fft.py to observe the spectrum
>  and see where the receiver thinks the peak of the spectrum is.  Then
> adjust your '-f' accordingly on a subsequent run of benchmark_rx.py.
>
> Crystal oscillators aren't perfect.  Even an error of a few 10s of PPM can
> add up to several Khz at center frequencies in the hundreds of
>  MHz.  Unless the receive flow-graph has a way of correcting gross
> frequency error, you will have to do that manually.
>
> This is such a common problem that I'm surprised you haven't covered it in
> your coursework yet.  Real radios (and radio channels) have
>  impairments that often aren't adequately modelled by simulations.
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>


Can someone put this in the FAQ page on gnuradio.org? It probably deserves
a more detailed explanation than a FAQ-level answer, but it'd be a start.

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

Re: [Discuss-gnuradio] Question about benchmark_tx and benchmark_rx

[Marcus D. Leech]

On 14/12/11 09:41 PM, Tom Rondeau wrote:
>
>
>
> Can someone put this in the FAQ page on gnuradio.org
> ? It probably deserves a more detailed
> explanation than a FAQ-level answer, but it'd be a start.
>
> Tom
>  
The fabled "someone" must have anticipated you:

http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#I-have-two-USRPs-and-when-I-transmit-on-one-and-receive-on-the-other-at-the-same-frequency-I-get-an-offset



-- 
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] Monthly Developers call

[Tom Rondeau]

We will be having our monthly call tomorrow. Same time and details as usual.

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

I'll try to post an agenda, but I don't have much right now. Mostly, we are
looking to planning what features we're looking for in the 3.6 release.

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

[Discuss-gnuradio] Costas loop and M&M algorithm on FPGA

[Phone Naing MYINT]

Hi,

Anyone here implemented freq/phase correction and symbol timing correction in 
USRP's FPGA?

Recently I implemented Costas loop and Muller & Mueller algorithm in RTL by 
referring the gnuradio code. Now I'm testing it on FPGA. I can get correct 
demodulated data(DQPSK) at initial few thousand symbols. After that I'm getting 
all rubbish data.

I think the problem with my RTL implementation is not good enough 
bit-resolution (unlike implementation on PC). Currently I'm using 15-bits 
resolution for decimal part. Anyone has any suggestion ?

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