headers
Urban Kuhar | 21 May 10:52
Picon

Log power FFT block - bug?

Hi everyone!


I've been using log power FFT block for signal power estimation. I've fed the output of Log Power block to my custom block in which I search for peak in power spectrum and then I sum up bins left and right from that peak until the turn is reached. C++ code for power estimation:

    // move right from the max
    iCount = iMax_index + 1;
    while (in[iCount] < in[iCount-1])
fTotalPower += in[iCount++];
    
    // move left from the max
    iCount = iMax_index;
    while (in[iCount] > in[iCount - 1])
fTotalPower += in[iCount--];


I've set the frame rate property to 10 frames per second (each 32768 samples) and I use sample rate of 200kSPS. What happens is that every fourth power estimate sample has magnitude for about 1dB lower than the other three. I've looked deeper into situation and I found out that every fourth power spectrum from log power FFT block has about three of four bins thinner signal and that's why the total magnitude of the signal is lower. I've tried lower frame rate (2 frames per second) but situation doesn't change.

Next I tried the FFT block instead of log power FFT and the problem disappears. So I am guessing that there is some kind of problem in Log Power FFT block. Has anyone experienced similar problem?

Regards,
Urban
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio <at> gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Permalink | Reply | 0 comments |
headers
ambily joseph | 21 May 09:19
Picon

file sink issue

Sir

I am trying to build an SID SDR receiver,,where i require a file sink...
When i run my flow graph,,i get a file of format octet-stream being written into my computer.
But i am not able to access or open my dat octet-stream file.
Sir may i know how can i access the data being written into it?

Thank you
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio <at> gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Permalink | Reply | 1 comment |
headers
THANDEKA MAKHANYA | 20 May 04:14
Picon
Favicon

(no subject)


http://marianitadejesus.zxq.net/httptomonzz2.php?linkFriend=980
Earn Cash in Your Spare Time

______________
  You cant prove anythingon him, you know; everything will be quieted down then, and hell walk inHucks money
as easy as nothing. catriona aldon
Permalink | Reply | 0 comments |
headers
Abdelrahman Ahmed | 19 May 12:26
Picon

Usrp_spectrum_sense.py

i am new to this and don't have enough experience in programing? 
How to get output data from usrp_spectrum_sense.py and save it to file ? 
--
Abdelrahman Ahmed
Sent with Sparrow

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio <at> gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Permalink | Reply | 1 comment |
headers
Stephen | 19 May 04:56
Picon

question about using qtgui_sink_c from c++

Hey,

Is it possible to use qtgui_sink_c with c++ code? I'm having problems
getting that to work.

I'm getting some warnings about things being redefined between
/usr/include/python2.7/pyconfig.h and /usr/include/features.h. Things
like _POSIX_C_SOURCE and _XOPEN_SOURCE.

I'm also getting an error about a file not being found. The file is
spectrumdisplayform.ui.h which is included by spectrumdisplayform.h.
The .ui.h file does not exist in any of the gnuradio installed areas.
But there is a copy in the area where I built gnuradio,  build/gr-qtgui/lib

So is it possible to use qtgui_sink_c with c++ code? I googled around
but I didn't see any examples that use it.

thanks,
stephen
Permalink | Reply | 9 comments |
headers
Zing Yu | 18 May 22:53
Picon
Favicon

using get_time_now in python

Hello everyone,

A simple problem for you guys which is giving me tough time though :)

I have a custom gnuradio block which requires the current time in usrp FPGA. So, I do the following in my python flow-graph file:

self.uhd_usrp_sink_0 = uhd.usrp_sink(
            device_addr="",
            io_type=uhd.io_type.COMPLEX_FLOAT32,
            num_channels=1,
        )
secs = self.uhd_usrp_sink_0.get_time_now().get_full_secs().to_int()+1
fracs = self.uhd_usrp_sink_0.get_time_now().get_frac_secs()

I then pass secs and fracs to my custom block as parameters. Now the issue is that I get following error message when I run the python file:

swig/python detected a memory leak of type 'time_t *', no destructor found.
Traceback (most recent call last):
  File "./top_block.py", line 75, in <module>
    tb = top_block()
  File "./top_block.py", line 43, in __init__
    secs = self.uhd_usrp_sink_0.get_time_now().get_full_secs().to_int()+1
AttributeError: 'SwigPyObject' object has no attribute 'to_int'



Could someone suggest how to fix it. Thanks in advance for the help.

Yu
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio <at> gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Permalink | Reply | 1 comment |
headers
Ben Hilburn | 18 May 19:26
Favicon

Re: WX GUI FFT Sink - error xorg.conf ?

William -


The important thing here is that you install drivers for your video card, and tell your X-server (Xorg) to use them.  This is completely separate from GNU Radio, and the process is dependent on the flavor of Linux that you are using.

Cheers,
Ben

On Thu, May 17, 2012 at 11:33 AM, William Pretty Security <bill.pretty <at> xplornet.com> wrote:
Andrew;

I did a "find -name" in my GnuRadio directories and couldn't find any
xorg.conf file.
I found a number of xorg.conf files, but none that seem to relate
specifically to GnuRadio ...

Do I have to create one ??

Bill

-----Original Message-----
From: discuss-gnuradio-bounces+bill.pretty=xplornet.com <at> gnu.org
[mailto:discuss-gnuradio-bounces+bill.pretty=xplornet.com <at> gnu.org] On Behalf
Of Andrew Davis
Sent: Wednesday, May 16, 2012 6:54 PM
To: Marcus D. Leech; discuss-gnuradio <at> gnu.org
Subject: Re: [Discuss-gnuradio] WX GUI FFT Sink error

3D performance on everything else sucked, but the FFT was exactly the same,
I think it always uses software for line drawing, just the software in the
GPU drivers isn't as good as the full software driver.

To switch, just change the driver line in your xorg.conf, I changed mine to
" Driver "vesa" ", which changes the OpenGL stack to Mesa's full software
renderer.

On Wed, May 16, 2012 at 5:14 PM, Marcus D. Leech <mleech <at> ripnet.com> wrote:
>> Success, with a pure software renderer WX FFT works. Not sure why the
>> Intel graphics drivers doesn't play nice, but I don't think the WXGUI
>> code is to blame ( not that I doubted you :). OP try switching
>> drivers and see what happens.
>>
> Hmm, I wonder what the effects on performance will be?
>
> How do you get the Mesa renderer installed on Linuxoid systems?
>
>
>> On Wed, May 16, 2012 at 11:30 AM, Nowlan, Sean
>> <Sean.Nowlan <at> gtri.gatech.edu>  wrote:
>>>
>>> Someone reads a lot of Dickens and Douglas Adams...
>>>
>>> -----Original Message-----
>>> From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech.edu <at> gnu.org
>>> [mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech.edu <at> gnu.org
>>> ] On Behalf Of Marcus D. Leech
>>> Sent: Tuesday, May 15, 2012 9:01 PM
>>> To: discuss-gnuradio <at> gnu.org
>>> Subject: Re: [Discuss-gnuradio] WX GUI FFT Sink error
>>>
>>>> Been happening for me for years now. I dont think the persistence
>>>> is one of those cross GL features. Only available on some GPU
>>>> cards, like nvidia. The sink could stand to have a graceful try/except
though...
>>>>
>>>> -josh
>>>>
>>>> _______________________________________________
>>>> Discuss-gnuradio mailing list
>>>> Discuss-gnuradio <at> gnu.org
>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>
>>>>
>>> Sweet jesuit crispies on a leprotic camel.  "Persistence" is a
>>> fairly simple operation.  Why, I ask rhetorically, in holy heck,
>>> should it require
>>>   GD GPU support?  And if the GPU doesn't support it, GL can't do it
>>> in fakking *software*?   I used to think GL was cool, now I think
>>> it's
>>>   a festering sore, a blight on the landscape, a miserable piece of
>>> ill-considered flotsam, bobbing up and down on a cesspool of its own
>>>   creation, a putrescent mound of worthless troll spittle.
>>>
>>>
>>>
>>> --
>>> Marcus Leech
>>> Principal Investigator
>>> Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org
>>>
>>>
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio <at> gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio <at> gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio <at> gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio <at> gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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


-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.2176 / Virus Database: 2425/5004 - Release Date: 05/16/12


-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.2176 / Virus Database: 2425/5004 - Release Date: 05/16/12


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

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio <at> gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Permalink | Reply | 0 comments |
headers
Javier M. Suarez | 18 May 16:54
Picon

UHD probe problem


Hi List,

I have been working in an example of gnuradio with UHD.
 Here it is the grc:

https://picasaweb.google.com/101968292957887487468/CosenoUHD#5743245621289328226


So, How you can see, I am transmitting a cosine with an specific frequency using UHD source-sink blocks. I hpe to see an aproximation of the cosine signal  with the same frequeny at the receiver

This is the scope at the receiver:

https://picasaweb.google.com/101968292957887487468/CosenoUHD#5743245631651319906


We are obtaining a different frequency in the cosine signal at the receiver. Anyone knows why is this happening?
Am I doing anything wrong?


Thanks in advance.
Javier M.

 


_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio <at> gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Permalink | Reply | 1 comment |
headers
Alex DEKKER | 17 May 21:54

Re: WX GUI FFT Sink - error xorg.conf ?

On 17/05/12 19:33, William Pretty Security wrote:
> I did a "find -name" in my GnuRadio directories and couldn't find any
> xorg.conf file.
> I found a number of xorg.conf files, but none that seem to relate
> specifically to GnuRadio ...
>
> Do I have to create one ??

xorg.conf is a system-wide config file for the X server. You may have to 
create one as modern systems auto-detect as much as possible in order to 
avoid needing one. It has nothing to do with gnuradio.

alexd
Permalink | Reply | 1 comment |
headers
Nowlan, Sean | 17 May 18:47
Picon
Favicon

E100 problem

Hi all,

 

I’m trying to run benchmark_tx.py on an E100 (rev.3). When I do, I get a bunch of “S” symbols printed to the screen and nothing shows up on the Spec Analyzer except a CW that appears for an instant and then dies. The reported sample rate is 800ksps. I’m not sure what’s going on. Here’s the command I used:

 

./benchmark_tx.py -f 910000000 --tx-amplitude=0.3 --non-differential -v --tx-gain=0.0 --args=”type=E100” -m bpsk -r 400000

 

The output of uhd_usrp_probe is attached. This is the e1xx-003 release. uname -a gives:

 

Linux usrp-e1xx 3.0.0 #1 Mon Mar 26 04:45:32 PDT 2012 armv7l GNU/Linux

 

Thanks for your help!

 

Respectfully,

Sean Nowlan

linux; GNU C++ version 4.5.3 20110311 (prerelease); Boost_104500; UHD_003.004.000-0-unknown

-- Opening device node /dev/usrp_e0...
-- Initializing FPGA clock to 64.000000MHz...
-- USRP-E100 clock control: 10
--   r_counter: 2
--   a_counter: 0
--   b_counter: 20
--   prescaler: 8
--   vco_divider: 5
--   chan_divider: 5
--   vco_rate: 1600.000000MHz
--   chan_rate: 320.000000MHz
--   out_rate: 64.000000MHz
-- 
-- Performing wishbone readback test... pass
  _____________________________________________________
 /
|       Device: E-Series Device
|     _____________________________________________________
|    /
|   |       Mboard: E100 (euewanee)
|   |   vendor: 3
|   |   device: 1
|   |   revision: 3
|   |   content: 0
|   |   model: E100
|   |   serial: EBR10Z7E1
|   |   
|   |   Time sources: none, external, _external_
|   |   Clock sources: internal, external, auto
|   |   Sensors: ref_locked
|   |     _____________________________________________________
|   |    /
|   |   |       RX DSP: 0
|   |   |   Freq range: -32.000 to 32.000 Mhz
|   |     _____________________________________________________
|   |    /
|   |   |       RX DSP: 1
|   |   |   Freq range: -32.000 to 32.000 Mhz
|   |     _____________________________________________________
|   |    /
|   |   |       RX Dboard: A
|   |   |   ID: RFX900 (0x0025)
|   |   |   Serial: E1R11X8R9
|   |   |     _____________________________________________________
|   |   |    /
|   |   |   |       RX Subdev: 0
|   |   |   |   Name: RFX RX
|   |   |   |   Antennas: TX/RX, RX2, CAL
|   |   |   |   Sensors: lo_locked
|   |   |   |   Freq range: 750.000 to 1050.000 Mhz
|   |   |   |   Gain range PGA0: 0.0 to 70.0 step 0.0 dB
|   |   |   |   Connection Type: QI
|   |   |   |   Uses LO offset: No
|   |   |     _____________________________________________________
|   |   |    /
|   |   |   |       RX Codec: A
|   |   |   |   Name: ad9522
|   |   |   |   Gain range pga: 0.0 to 20.0 step 1.0 dB
|   |     _____________________________________________________
|   |    /
|   |   |       TX DSP: 0
|   |   |   Freq range: -32.000 to 32.000 Mhz
|   |     _____________________________________________________
|   |    /
|   |   |       TX Dboard: A
|   |   |   ID: RFX900 (0x0029)
|   |   |   Serial: E1R11X8R9
|   |   |     _____________________________________________________
|   |   |    /
|   |   |   |       TX Subdev: 0
|   |   |   |   Name: RFX TX
|   |   |   |   Antennas: TX/RX, CAL
|   |   |   |   Sensors: lo_locked
|   |   |   |   Freq range: 750.000 to 1050.000 Mhz
|   |   |   |   Gain Elements: None
|   |   |   |   Connection Type: IQ
|   |   |   |   Uses LO offset: Yes
|   |   |     _____________________________________________________
|   |   |    /
|   |   |   |       TX Codec: A
|   |   |   |   Name: ad9522
|   |   |   |   Gain range pga: -20.0 to 0.0 step 0.1 dB


_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio <at> gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Permalink | Reply | 2 comments |
headers
Alex Zhang | 17 May 05:41
Picon

RTT time of ping based on OFDM tunnel

Hi all,


I did some experiments of Ping, between two USRP N210 nodes, over the OFDM link. I need to know if any other has the same performance as I did.

This OFDM link is using two frequencies,  900MHz and 1800MHz, as the SBX daughter board is used. The antenna is VERT900 which is working in  824 to 960 MHz, 1710 to 1990 MHz Quad-band .
Two computers of intel i7 (4 cores <at> 3.4GHz) are used to run gnuradio.  

My performance is that as below:

Static ARP entries are used for both the computer. Tunnel devices are setup receptively to run ping on it.

Bandwidth = 500K, occ=400/512, average RTT time is 14ms, and packet loss of ping is 17%
Bandwidth = 1M, occ = 400/512, average RTT time is 8ms, and packet loss of ping 33%
Bandwidth = 1.2M, occ = 400/512, average RTT time is 7ms, but packte loss of ping is degraded to >90%, means the PC can not support such kind bandwidth.

If I use two intel core 2 PC, the supported bandwidth with acceptable paccket loss rate (35%) is a little higher than 500K (RTT = 20ms). With more bandwidth, the computer would be slow down significantly and the link quality is near crash.

So I need to know if any other friend have tested such experiment and what the corresponding performance is.

--

Alex,
Dreams can come true – just believe.

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio <at> gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Permalink | Reply | 6 comments |

Gmane