Re: [Discuss-gnuradio] Failed Install + gr-osmosdr Troubles

2013-12-12 Thread Martin Braun (CEL) 
On Wed, Dec 11, 2013 at 06:52:30PM -0500, Marcus Leech wrote:
> >Just for fun I uninstalled everything and tried installing with
> >pybombs. However when it got to the step which builds
> >filter_swigPYTHON_wrap there was an issue:
> >
> >[ 78%] Building CXX object
> >gr-filter/swig/CMakeFiles/_filter_swig.dir/filter_swigPYTHON_wrap.cxx.o
> >
> >c++: internal compiler error: Killed (program c11plus)
> > [...]
> That's generally due to gpp running out of memory during processing
> of the fairly-chunky SWIG files.  Add more RAM to your system, or
> add a
>   swap/paging file see "mkswap" and "swapon".

Also, I've sometimes seen the compiler crash on a SWIG file, but run
fine if I try again. Did you try this multiple times?

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


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

Re: [Discuss-gnuradio] Bit error rate test

2013-12-12 Thread Martin Braun (CEL) 
On Wed, Dec 11, 2013 at 04:15:11PM -0700, Henry Jin wrote:
> I tried to use digital_bert_tx.py and digital_bert_rx.py to test the BER
> performance of different modulations. The command I use is 
> ./digital_bert_tx.py
> --tx-freq=5.1e9 --tx-gain=30 -S 8 --mod-code=gray -m bpsk. The results for 
> BPSK
> is good enough. When SNR is above 20, the BER is around 10^(-11). However, 
> when
> I change the modulation to QPSK, the BER is only around 0.167 although it says
> SNR is still around 20. Surely there is something wrong. 16QAM has the same
> problem. Just wonder if anyone has the same experience before. Am I missing
> something in order to correctly use the test script?

Henry,

I believe you've run into the famous 'SNR' trap[1], where you're using
the wrong definition of SNR for your purposes.
I'd need to have a closer look at the blocks in question, but I believe
your estimate is actually the E_S/N_0 (it might be something within a
constant factor of this).
The relevant quantity for predicting BER is E_b/N_0. If you increase the
modulation (BPSK -> QPSK -> QAM), you're decreasing the latter (at
constant 'SNR'). So, all is fine.

I'm a bit surprised about the actual values. If you're measuring a BER
of 10**-11, that means you're transmitting data on the order of 10**12 bits?
I'm not 100% familiar with digital_bert_tx.py, but this seems weird.

Note that there are formulas to derive the BER from EbN0. Remember they
apply to the AWGN channel only. If you have synchronisation,
equalization etc. BER will get worse.
So, .167 is more than the theory says, but you'd expect more anyway.

MB

[1] Well, don't know if it's famous. It's a very common mistake, though.

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


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

[Discuss-gnuradio] UHD USRP sink does not react to gain changes (gr-ieee802-11: between two usrp devices)

2013-12-12 Thread Nasi 
 Dear All,

I need your help. May be any of you had such a problem before:

I use 'IEEE 802.11 a/g/p OFDM Transceiver' project, Ubuntu 13.04, GNURADIO 3.7 
and (USRP N200 + XCVR 2450 + VERT2450 antenna).
I start the transmission using the first laptop and USRP N200 device by running 
the ./ofdm_tx.py.
Meanwhile I use the second laptop and USRP N200 device as the receiver by 
running the ./ofdm_rx.py. The error rate is very high.

The problem is that when I change gain in the USRP sink nothing changes (i 
tested it using 'wxgui_fftsink'). 
(I think it is a software problem since I tested it with another project. There 
it changes when I change gain.)

Do you know what can cause this? 
Why transmission side (USRP sink) does not change according to the gain at all?

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

[Discuss-gnuradio] Unexpected issue with file source and USRP source

2013-12-12 Thread Maria Stevens 
GNU Radio Companion v3.6.4-43-g6e5dfe1a
linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.005.001-37-g21311276
USRP N210

Hello All !

I am observing following 3 cases for same transmitter. I ran each case
multiple times and reach to conclusion that only CASE 1 is working fine.

CASE 1:

First i execute flowgraph1.grc in which there is
USRP Source --> File Sink (abc.bin)

After writing file i execute another  flowgraph2.grc that reads the
previously saved file 'abc.bin' as show below
File Source (abc.bin) --> throttle --> Demodulator chain

In this case, I am able to receive and decode all the sent packets
correctly.


CASE 2:

However, when I remove the file sink and directly connect the USRP with the
*same* demodulator chain, I observe frequent packet loss.

flowgraph3.grc
USRP Source --> Demodulator Chain

CASE 3 :

In this case I connected file sink and demodulator so that demodulator can
demodulate the incoming samples and at the same time USRP writes the
samples to a file 'def.bin'. This file is to be used for post processing to
compare results. Again I observed frequent packet loss.

flowgraph4.grc
USRP Source --> File sorce (def.bin)
 --> Demodulator Chain

after executing flowgraph4.grc , i execute flowgraph5.grc, post processing
of file 'def.bin'
File Source(def.bin)  --> throttle --> Demodulator chain
I observed same packet loss.

So, Only case 1 is working for me. I am not using any custom gnuradio-block
in my receiver. Major blocks in my demodulator chain consists of FIR
filters, gr_pfb_clock_sync_ccf and packet decoder along with some adders
subtractors etc. what is the difference caused by the same demodulator
chain when reading data directly from usrp source and from file source? is
it because some of the demodulator chain blocks are causing back pressure
due to taking too much time in processing but when run in real time it
causes data loss during exchange of samples between blocks.  I am confused
if in real time the gr_pfb_clock_sync_ccf block or any other major block
stucks in processing during which samples are lost due to new incoming
samples.

Any help would be appreciated.

Regards.

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

Re: [Discuss-gnuradio] Unexpected issue with file source and USRP source

2013-12-12 Thread Martin Braun (CEL) 
On Thu, Dec 12, 2013 at 03:54:29PM +0500, Maria Stevens wrote:
> So, Only case 1 is working for me. I am not using any custom gnuradio-block in
> my receiver. Major blocks in my demodulator chain consists of FIR filters,
> gr_pfb_clock_sync_ccf and packet decoder along with some adders subtractors
> etc. what is the difference caused by the same demodulator chain when reading
> data directly from usrp source and from file source? is it because some of the
> demodulator chain blocks are causing back pressure due to taking too much time
> in processing but when run in real time it causes data loss during exchange of
> samples between blocks.  I am confused if in real time the
> gr_pfb_clock_sync_ccf block or any other major block stucks in processing
> during which samples are lost due to new incoming samples.

Are you observing overflows? If so, have you tried reducing the
bandwidth and see if that helps?

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


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

Re: [Discuss-gnuradio] UHD USRP sink does not react to gain changes (gr-ieee802-11: between two usrp devices)

2013-12-12 Thread Bastian Bloessl 

On 12 Dec 2013, at 11:31, Nasi  wrote:

> Meanwhile I use the second laptop and USRP N200 device as the receiver by 
> running the ./ofdm_rx.py. The error rate is very high.
> 

So you receive some packets or none?

> The problem is that when I change gain in the USRP sink nothing changes (i 
> tested it using 'wxgui_fftsink'). 
> (I think it is a software problem since I tested it with another project. 
> There it changes when I change gain.)

Can you please be a litte bit more verbose? Where do you plug in the FFT sink? 
What do you see? What did you expect to see.

If you plug it in after the USRP block it is not a problem of the receiver, but 
here the actual signal might be hard to spot. In that case I would try 
gr-fosphor. If it is after the signal has been normalised it is obviously 
independent from the gain setting. I started a readme file with some tips (see 
github) maybe you find something interesting in there.

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

[Discuss-gnuradio] OFDM Transmitter GRC Example

2013-12-12 Thread ZaInzAiN Jj 
Dear all,
In OFDM transmitter example there is "Stream to Tagged Stream" block with 
packet length value 96. What it's mean? And whether the value claim specific 
standard?

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

Re: [Discuss-gnuradio] UHD USRP sink does not react to gain changes (gr-ieee802-11: between two usrp devices)

2013-12-12 Thread Nasi 

> Meanwhile I use the second laptop and USRP N200 device as the receiver by 
> running the ./ofdm_rx.py. The error rate is very high.
>> 
>
>So you receive some packets or none? Yes, I receive hopefully. But the packer 
>error rate is too high. I went through different configurations and gains. And 
>finally I see that the problem is the transmission side. The gain does not 
>have any influence on the error rate.
>
>> The problem is that when I change gain in the USRP sink nothing changes (i 
>> tested it using 'wxgui_fftsink'). 
>> (I think it is a software problem since I tested it with another project. 
>> There it changes when I change gain.)
>
>Can you please be a litte bit more verbose? Where do you plug in the FFT sink? 
>What do you see? What did you expect to see. Yes, sure. So I attach FFT sink 
>to the USRP source in the ofdm_rx.grc. You should see an FFT plot like a 
>normal FFT block. I set FFT size to 64 and frequency to the frequency which I 
>transmit or receive. Ok. lets say we do not care what we see, but when I 
>change the gain in the transmitter nothing changes in the plot. You know that 
>the curve dB should go higher, isn't it? However in this case the receiver 
>signal dB is below -80 dB which showa that there is very low signal.
Even I detach the antenna it works, funnily. I testet this with benchmarks to 
see if it is a hardware problem or not. It seems like smt. is wrong in the 
transmission side.  Do you have any idea what can cause it?
>
>
>If you plug it in after the USRP block it is not a problem of the receiver, 
>but here the actual signal might be hard to spot. In that case I would try 
>gr-fosphor. If it is after the signal has been normalised it is obviously 
>independent from the gain setting. I started a readme file with some tips (see 
>github) maybe you find something interesting in there.
>
>Bastian

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

Re: [Discuss-gnuradio] OFDM Transmitter GRC Example

2013-12-12 Thread Martin Braun (CEL) 
On Thu, Dec 12, 2013 at 08:27:19PM +0800, ZaInzAiN Jj wrote:
> This is OFDM transmitter grc file
> 
> 
> On Thursday, December 12, 2013 7:22 PM, ZaInzAiN Jj 
> wrote:
> Dear all,
> In OFDM transmitter example there is "Stream to Tagged Stream" block with
> packet length value 96. What it's mean? And whether the value claim specific
> standard?

See the manual:
http://gnuradio.org/doc/doxygen/page_tagged_stream_blocks.html

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


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

Re: [Discuss-gnuradio] UHD USRP sink does not react to gain changes (gr-ieee802-11: between two usrp devices)

2013-12-12 Thread Bastian Bloessl 

On 12 Dec 2013, at 15:26, Nasi  wrote:

> Yes, I receive hopefully. But the packer error rate is too high. I went 
> through different configurations and gains. And finally I see that the 
> problem is the transmission side. The gain does not have any influence on the 
> error rate.

Just to be sure: do you have the current version? (some weeks ago I normalized 
the signal power to 1 without pushing updates of the flow graphs. That lead to 
distorted signals. In that case, changing the gain does not help.)

> 
> Can you please be a litte bit more verbose? Where do you plug in the FFT 
> sink? What do you see? What did you expect to see.
> Yes, sure. So I attach FFT sink to the USRP source in the ofdm_rx.grc. You 
> should see an FFT plot like a normal FFT block. I set FFT size to 64 and 
> frequency to the frequency which I transmit or receive. Ok. lets say we do 
> not care what we see, but when I change the gain in the transmitter nothing 
> changes in the plot. You know that the curve dB should go higher, isn't it? 
> However in this case the receiver signal dB is below -80 dB which showa that 
> there is very low signal.
> Even I detach the antenna it works, funnily. I testet this with benchmarks to 
> see if it is a hardware problem or not. It seems like smt. is wrong in the 
> transmission side.  Do you have any idea what can cause it?

Thanks, I guess the problem is that just very few samples of your incoming 
stream belong to WiFi frames. So chances are that the frame is not visualised 
at all (I think that the FTT sink uses a subset of the samples based on the 
sample rate and the update rate of the GUI). If you really want to stick to 
this approach I would recommend to  checkout gr-fosphor. I found it really 
helpful.

https://www.youtube.com/watch?v=mjD-l3GAghU

Best,
Bastian


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

Re: [Discuss-gnuradio] UHD USRP sink does not react to gain changes (gr-ieee802-11: between two usrp devices)

2013-12-12 Thread Nasi 

>Just to be sure: do you have the current version? (some weeks ago I normalized 
>the signal power to 1 without pushing updates of the flow graphs. That lead to 
>distorted signals. In that case, changing the gain does not help.) I 
>reinstalled it previous week, I guess on Saturday. Before it was not working 
>at all. I think this can cause a problem... Where do you normalize that? 
 
>Thanks, I guess the problem is that just very few samples of your incoming 
>stream belong to WiFi frames. So chances are that the frame is not visualised 
>at all (I think that the FTT sink uses a subset of the samples based on the 
>sample rate and the update rate of the GUI). If you really want to stick to 
>this approach I would recommend to  checkout gr-fosphor. I found it really 
>helpful. No, I changed the transmission frequency to smt. different 5.94. If I 
>don't run tx, rx receives nothing. When I start tx rx starts to receive smt. 
Another thing I think the frame is visualized since when I increase rx gain in 
receiver side the curve goes higher. 

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

[Discuss-gnuradio] Strange Received Signal for 2x1 MISO OFDM (sometimes!)

2013-12-12 Thread David Halls 
Hi,

I am trying to transmit 2x1 MISO OFDM. The two transmit USRPs are connected by 
MIMO cable, and the USRP sink section of the .py file is:

self.uhd_usrp_sink_0_0_0 = uhd.usrp_sink(
device_addr="addr0=192.168.10.2,addr1=192.168.10.7",
stream_args=uhd.stream_args(
cpu_format="fc32",
otw_format="sc16",
channels=range(2),
),
)
self.uhd_usrp_sink_0_0_0.set_clock_source("mimo", 1)
self.uhd_usrp_sink_0_0_0.set_time_source("mimo", 1)
self.uhd_usrp_sink_0_0_0.set_samp_rate(samp_rate)
self.uhd_usrp_sink_0_0_0.set_center_freq(uhd.tune_request(center_freq, 
rf_freq=(center_freq + 
lo_offset),rf_freq_policy=uhd.tune_request.POLICY_MANUAL), 0)
self.uhd_usrp_sink_0_0_0.set_gain(tx_gain, 0)
self.uhd_usrp_sink_0_0_0.set_antenna(tx_ant, 0)
self.uhd_usrp_sink_0_0_0.set_center_freq(uhd.tune_request(center_freq, 
rf_freq=(center_freq + 
lo_offset),rf_freq_policy=uhd.tune_request.POLICY_MANUAL), 1)
self.uhd_usrp_sink_0_0_0.set_gain(tx_gain, 1)
self.uhd_usrp_sink_0_0_0.set_antenna(tx_ant, 1)

At the receiver I sometimes get a very strange response - see attached picture.

If I use an external PPS signal, and set sync to 'Unknown PPS', the occurrence 
of this strange signal - where some parts of the signal seem to just be a noisy 
sinusoid, is *dramatically* reduced - but not avoided always. Using 'PC Clock' 
does not improve the situation.

Is there something obviously wrong with the way I am trying to transmit over 
two USRPs simultaneously? I am not clearly why the problem is intermittent. All 
3 USRPs are connected two one PC, they are N210s with XCVR2450s, tx gain = 0, 
rx gain = 0, centre freq = 2.4GHz, samp rate = 1M.

Regards,

David





NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl



Scanned by MailDefender - managed email security from intY - 
www.maildefender.net<>___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] [VOLK] Summary of call

2013-12-12 Thread West, Nathan 
The VOLK working group had a call earlier today. Agenda and summary
are here: http://gnuradio.org/redmine/projects/gnuradio/wiki/Call20131212

We'll likely have our next call late January or February time-frame.

There's a semi-open question about what kind of stats we should
collect. Tim added support for taking CFLAGS at build time and
/proc/version and /proc/cpuinfo at runtime. While we're at it are
there any other machine features that would be useful to collect?


-Nathan

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

Re: [Discuss-gnuradio] Minimum amount of data to trigger WX GUI Scope Sink? and Ch 1 vs. Ch2 with Ch 3 vs. Ch 4

2013-12-12 Thread Wayne Roberts 
The trigger of scope sink is not for XY mode.

If you want to view two complex signal simultaneous, then it seems you need
two scope sinks.

If you dont see anything, maybe you have a block driving it that doesnt
output anything until some condition is met.


On Wed, Dec 11, 2013 at 10:53 AM, David Halls
wrote:

>  Hi,
>
> I am using WX GUI Scope Sink, and I have set the sample rate = 1M, same as
> the USRP. It seems that a minimum number of data points are required before
> anything appears on the plot - is that correct, and how can it be adjusted?
>
> Also, I am looking at constellations, using the XY mode to show real and
> imaginary. It is possible to have multiple inputs, but is it possible to
> view multiple 'series' in XY mode?
>
> I seem to be only able to choose Ch X vs Ch Y, e.g. Ch 1 vs. Ch 2 (
> Re(in1) vs. Im(in1) ) or Ch 1 vs. Ch 4 (Re(in1) vs. Im(in2)). I would like
> to see Ch 1 vs. Ch 2 and Ch 3 vs Ch 4 simultaneously?
>
> Thanks in advance! :)
>
> David
>
> --
>
> NOTE: The information in this email and any attachments may be
> confidential and/or legally privileged. This message may be read, copied
> and used only by the intended recipient. If you are not the intended
> recipient, please destroy this message, delete any copies held on your
> system and notify the sender immediately.
>
> Toshiba Research Europe Limited, registered in England and Wales
> (2519556). Registered Office 208 Cambridge Science Park, Milton Road,
> Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl
>
>  *Scanned by MailDefender - managed email security from intY -
> www.maildefender.net *
> ___
> 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] [VOLK] Summary of call

2013-12-12 Thread Douglas Geiger 
On Thu, Dec 12, 2013 at 3:11 PM, West, Nathan
wrote:

> The VOLK working group had a call earlier today. Agenda and summary
> are here: http://gnuradio.org/redmine/projects/gnuradio/wiki/Call20131212
>
> We'll likely have our next call late January or February time-frame.
>
> There's a semi-open question about what kind of stats we should
> collect. Tim added support for taking CFLAGS at build time and
> /proc/version and /proc/cpuinfo at runtime. While we're at it are
> there any other machine features that would be useful to collect?
>
>
Toolchain name/version info please! (http://gnuradio.org/redmine/issues/620)

Unless, of course, Tim's support for CFLAGS already includes that info
and/or patch...


-- 
Doug Geiger
doug.gei...@bioradiation.net
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [VOLK] Summary of call

2013-12-12 Thread Tim 
On 12/12/2013 04:01 PM, Douglas Geiger wrote:
> On Thu, Dec 12, 2013 at 3:11 PM, West, Nathan
> mailto:n...@ostatemail.okstate.edu>> wrote:
>
> The VOLK working group had a call earlier today. Agenda and summary
> are here:
> http://gnuradio.org/redmine/projects/gnuradio/wiki/Call20131212
>
> We'll likely have our next call late January or February time-frame.
>
> There's a semi-open question about what kind of stats we should
> collect. Tim added support for taking CFLAGS at build time and
> /proc/version and /proc/cpuinfo at runtime. While we're at it are
> there any other machine features that would be useful to collect?
>
>
> Toolchain name/version info please!
> (http://gnuradio.org/redmine/issues/620)
>
> Unless, of course, Tim's support for CFLAGS already includes that info
> and/or patch...
>

Yep, already working on including compiler name / version as well

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

Re: [Discuss-gnuradio] [VOLK] Summary of call

2013-12-12 Thread Tom Rondeau 
On Thu, Dec 12, 2013 at 4:07 PM, Tim  wrote:
> On 12/12/2013 04:01 PM, Douglas Geiger wrote:
>
> On Thu, Dec 12, 2013 at 3:11 PM, West, Nathan 
> wrote:
>>
>> The VOLK working group had a call earlier today. Agenda and summary
>> are here: http://gnuradio.org/redmine/projects/gnuradio/wiki/Call20131212
>>
>> We'll likely have our next call late January or February time-frame.
>>
>> There's a semi-open question about what kind of stats we should
>> collect. Tim added support for taking CFLAGS at build time and
>> /proc/version and /proc/cpuinfo at runtime. While we're at it are
>> there any other machine features that would be useful to collect?
>>
>
> Toolchain name/version info please! (http://gnuradio.org/redmine/issues/620)
>
> Unless, of course, Tim's support for CFLAGS already includes that info
> and/or patch...
>
>
> Yep, already working on including compiler name / version as well

Yeah. Tim and I have been working on this. Should be able to merge it
soon. Adds '--cc', '--cxx', and '--cflags' to gnuradio-config-info to
get the information we used to compile with. Also created a new
volk-config-info program that gives similar information about the VOLK
build.

I updated the dev call wiki page with some info on this.

Tom

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

Re: [Discuss-gnuradio] Bit error rate test

2013-12-12 Thread Henry Jin 
Thanks for your reply, Martin.

I can understand your point that the estimated SNR in the script
corresponds to ES/N0, which should be twice of Eb/N0 in the case of qpsk.

You do raise a good question: why the BER is shown as 10^(-11)? I rechecked
the script. The default bit rate is 250e3, which is far lower than the
required number to generate a BER at the level shown. The main function
associated with the BER is
# Measure BER by the density of 0s in the stream
self._ber = digital.probe_density_b(1.0/self._symbol_rate)
I haven't checked the details of the above function, though. Anyone has any
thoughts on this?

Henry


Date: Thu, 12 Dec 2013 09:26:48 +0100
From: "Martin Braun (CEL)" 

On Wed, Dec 11, 2013 at 04:15:11PM -0700, Henry Jin wrote:
 > I tried to use digital_bert_tx.py and digital_bert_rx.py to test the BER
 > performance of different modulations. The command I use is
./digital_bert_tx.py
 > --tx-freq=5.1e9 --tx-gain=30 -S 8 --mod-code=gray -m bpsk. The results
for BPSK
 > is good enough. When SNR is above 20, the BER is around 10^(-11).
However, when
 > I change the modulation to QPSK, the BER is only around 0.167 although
it says
 > SNR is still around 20. Surely there is something wrong. 16QAM has the
same
 > problem. Just wonder if anyone has the same experience before. Am I
missing
 > something in order to correctly use the test script?
 Henry,
 I believe you've run into the famous 'SNR' trap[1], where you're using
 the wrong definition of SNR for your purposes.
 I'd need to have a closer look at the blocks in question, but I believe
 your estimate is actually the E_S/N_0 (it might be something within a
 constant factor of this).
 The relevant quantity for predicting BER is E_b/N_0. If you increase the
 modulation (BPSK -> QPSK -> QAM), you're decreasing the latter (at
 constant 'SNR'). So, all is fine.
 I'm a bit surprised about the actual values. If you're measuring a BER
 of 10**-11, that means you're transmitting data on the order of 10**12
bits?
 I'm not 100% familiar with digital_bert_tx.py, but this seems weird.
 Note that there are formulas to derive the BER from EbN0. Remember they
 apply to the AWGN channel only. If you have synchronisation,
 equalization etc. BER will get worse.
 So, .167 is more than the theory says, but you'd expect more anyway.
 MB
 [1] Well, don't know if it's famous. It's a very common mistake, though.
 --
 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
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio