from:"Henry Jin"

Re: [Discuss-gnuradio] benchmark_rx.py segmentation fault

2015-05-01 Thread Henry Jin

I remember I had the same issue before when testing the benchmark. What I
did to avoid the crash is to start the tx first, and then the rx. It seems
that you are doing it in reverse order, which is reasonable but not working
according to my test.

On Fri, May 1, 2015 at 10:51 AM, Richard Bell richard.be...@gmail.com
wrote:

I forgot to mention that I also re-cloned pybombs before doing the update.
So to be explicit, I deleted the target and pybombs directory. I then
re-cloned pybombs and performed a new ./pybombs install gnuradio. This
recognized I had all dependencies installed via rpm and only needed to
remove and re-install uhd and gnuradio. It then did this.

As I mentioned, my custom radio flowgraph is working on this updated
system.

v/r,
Rich

On Fri, May 1, 2015 at 10:46 AM, Richard Bell richard.be...@gmail.com
wrote:

I use pybombs to update, which automatically updates UHD first and then
GNU Radio.

Rich

On Fri, May 1, 2015 at 10:20 AM, Martin Braun martin.br...@ettus.com
wrote:

Did you update GNU Radio *after* you updated UHD? If not, that's what
you should do.

http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#My-application-segfaults-immediately-It-used-to-work-and-I-didnt-change-it-What-the

On 30.04.2015 08:59, Richard Bell wrote:
Hello,

I'm using Ubuntu 14.04, gnuradio 3.7.8, USRP N210 and the latest UHD.
Everything was recently (3 days ago) updated to newest versions and
USRP's reflashed. I have custom flowgraphs that use the USRP N210's
that
work fine.

I decided to play around with the benchmark_tx and benchmark_rx scripts
to see what they could do, but I'm not able to receive anything because
a segmentation fault crashes the benchmark_rx script as soon as I start
the tx script. Even with the -v flag, I don't get any error output
other
then 'Segmentation fault (core dumped)'.

Here is an example of the commands I use to start the scripts. I start
the rx and then the tx.

TX: *./benchmark_tx.py -v -f 10 -r 80
--args=addr=10.0.8.5
-A TX/RX --tx-gain=15*

RX: *./benchmark_rx.py -v -f 10 -r 80
--args=addr=10.0.8.4
-A RX2 --rx-gain=15 *

Am I doing something wrong on my end or is there a script issue?

Thanks,
Rich

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

Re: [Discuss-gnuradio] OFDM test with USRP

2015-03-19 Thread Henry Jin

Hi Martin,

Thanks for the FOSDEM 14 video on youtube (although maybe not posted by
you). Your talk is very informative and helpful.

On Thursday, March 19, 2015, Martin Braun martin.br...@ettus.com wrote:

 On 19.03.2015 14:11, Henry Jin wrote:

 Hi Marcus,

 I later added a throttle and time scope to the tx end to see how large
 the amplitude can be. Indeed, when the multiplier is 60m, the amplitude
 increases beyond 1, which will be clipped by the USRP driver. Setting it
 to be 0.45 seems like a safe choice.


 You might be able to push it a bit more. But definitely stay clear from 1.


There is a typo here. The max multiplier I can set is 0.045. This value is
based on the display on the time scope. The value ensures that every sample
stays below the limit of 1.



  For small amplitude cases such as when the multiplier is 20m, the SNR is
 also low. The reason the OFDM receiver fails to receive many packets is
 actually because the threshold used in digital.ofdm_sync_sc_cfb() for
 the plateau detector. Currently, the code leaves the threshold value to
 be default, which is 0.9. In low SNR cases, in fact, we need to set it
 smaller to tolerate noise. Originally, let's say the synchronization
 rate is only 1% or even lower, after this adjustment, it can be over
 90%. I suggest adding a parameter in ofdm_txrx.py to adjust this
 parameter.


 Hm. SC works fine for low SNRs, and changing the threshold is usually not
 required, due to normalization. I'd be hesitant to add that parameter,
 there might be another issue here. When you say low SNR, which regime are
 you talking about? Because the slicers (QPSK demapping) will usually fail
 before the detection.


Since there seems no available SNR estimators for OFDM yet in GNURadio, I
implemented one myself. Although it seems to be not quite accurate, but it
can serve as a reference. The low SNR I was talking about is around 13 dB.
The observation that motivates me to modify the threshold is that the
receiver can almost fully decode every packet it received (i.e., the PER is
quite low, around 2%). However, I noted that in fact many packets are
missing by observing the inconsistent packet_number in the tag debug at the
receiver end. Conservatively speaking, more than 80% missed. So I figure
that maybe it is because the sync module fails to detect a peak. By adding
some debug code, I am able to find the peak gap between each other is
random and large, not constant and small (It should be the exact or nearly
exact number of samples in the whole frame). So by lowering the threshold,
now it seems to be working as expected as now many packets can indeed be
received and decoded. To play safe, I only lower the threshold when needed.
If the SNR is high, default value can still be used.



  Back to the high SNR cases, one issue puzzling me now is that when the
 multiplier is 60m, although indeed there are samples exceeding the
 amplitude limitation of 1, many other samples (in fact most of them)
 have a small amplitude less than 0.5. This greatly limits the overall
 SNR we can get. I wonder if there can be any improvements over this?


 This is a well-known OFDM issue. You can choose an encoding that will
 limit PAPR, use pilot tones that decrease PAPR... and many other
 PAPR-reducing techniques.
 This also depends on how many subcarriers you use. For random data, your
 PAPR usually stays within 2*ln(N), which is usually not that bad.


I see. Currently, I'm using 48 data subcarriers out of 64 in total.



 Cheers,
 M

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


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

Re: [Discuss-gnuradio] OFDM test with USRP

2015-03-19 Thread Henry Jin

, for example, to 0.06. the PER
 is around 0.0044
That doesn't sound half bad, considering you don't do any equalizing. I
think (I'm not totally sure, was too lazy to look into the source code
just now) that the OFDM implementation (you're using the older one, the
newer one is cooler) doesn't do much on the receiving side to recover
the signal.
Have a look at the rx_ofdm example (in
/usr/[local/]share/gnuradio/examples/digital/, or so). That's a bit more
advanced than your RX.

Greetings,
Marcus

On 03/19/2015 01:34 AM, Henry Jin wrote:
 Hi everyone,

 I have built a tx and a rx grc flowchart for OFDM using USRP. I found
 the range of the amplitude of the input is fairly small in order to
 get it working (i.e., the USRP at the rx end can successfully decode
 the packets.)  I wound if anyone can share some thoughts about this?
 I've been stuck here for several days.


 To quantify the packet reception performance, I modified
 digital.crc32_bb so that even when the crc test fails, the wrong
 packet is still fed to the output. In this way, I can evaluate the
 packet error rate (PER). Through my test, I found the const in
 multiply_const in the tx part (which corresponds to amplitude
 adjustment) needs to be (0.05, 0.025). In this range, the PER can be
 0. However, when the const value increases, for example, to 0.06. the
 PER is around 0.0044. When we further increase the const value to
 0.08, the PER is above 10% or even higher. I guess this is probably
 because the input signal amplitude of the USRP needs to be in a
 certain working range.  However, it seems to me this range is too
 small. Besides, how can I find some numerical statistics about the
 amplitude limitation? On the other hand, if the amplitude is decreased
 to 0.02, many packets will be failed to synchronize. But I do observed
 that the packets successfully synchronized are also correctly decoded.
 In other words, the PER is still 0, but the number of packets
 correctly decoded is actually much smaller than the number of packets
 sent.

 I also tried to enable the two disabled blocks in the files but it is
 of no help.

 Thanks for any comments.

 link:
 https://www.dropbox.com/s/ndrtide1g73u5ju/grc_ofdm_rx.grc?dl=0
 https://www.dropbox.com/s/8g3kg2tg6pdh0dy/grc_ofdm_tx.grc?dl=0


 ___
 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] OFDM test with USRP

2015-03-19 Thread Henry Jin

Hi Marcus,

I later added a throttle and time scope to the tx end to see how large the
amplitude can be. Indeed, when the multiplier is 60m, the amplitude
increases beyond 1, which will be clipped by the USRP driver. Setting it to
be 0.45 seems like a safe choice.

For small amplitude cases such as when the multiplier is 20m, the SNR is
also low. The reason the OFDM receiver fails to receive many packets is
actually because the threshold used in digital.ofdm_sync_sc_cfb() for the
plateau detector. Currently, the code leaves the threshold value to be
default, which is 0.9. In low SNR cases, in fact, we need to set it smaller
to tolerate noise. Originally, let's say the synchronization rate is only
1% or even lower, after this adjustment, it can be over 90%. I suggest
adding a parameter in ofdm_txrx.py to adjust this parameter.

Back to the high SNR cases, one issue puzzling me now is that when the
multiplier is 60m, although indeed there are samples exceeding the
amplitude limitation of 1, many other samples (in fact most of them) have a
small amplitude less than 0.5. This greatly limits the overall SNR we can
get. I wonder if there can be any improvements over this?

Thanks
Henry

On Thu, Mar 19, 2015 at 10:17 AM, Henry Jin henry.ji...@gmail.com wrote:

 Hi Marcus,

 Thanks for your very detailed comments.

 My purpose of testing the PER is to facilitate evaluations on further
 modifications of the codes. I'd like to set up a benchmark like the ones I
 have shown and then draw a PER vs SNR curve to show the performance just
 like how we do evaluations theoretically. So I prefer to find the root
 cause of this phenomenon rather than using error correction
 or re-transmission.

  I'm a bit surprised, though -- you just feed in random information, and
  that should be white, which means that packets with unhealthily high
  PAPR are seldom.

 Originally, I feed in some fixed sequences. The working range of the const
 value is even smaller, around (0.035, 0.025). So later I replaced it with
 the random source. Indeed, I saw some improvement but yet not good enough.

  You should save the samples that come out of the OFDM mod block using a
  file sink, and analyze them later; look for samples with magnitude 1.0
  (they shouldn't be there, because the output of the internal IFFT is
  scaled with 1/sqrt(fftlen)).
   However, when the const value increases, for example, to 0.06. the PER
   is around 0.0044
  That doesn't sound half bad, considering you don't do any equalizing. I
  think (I'm not totally sure, was too lazy to look into the source code
  just now) that the OFDM implementation (you're using the older one, the
  newer one is cooler) doesn't do much on the receiving side to recover
  the signal.
  Have a look at the rx_ofdm example (in
  /usr/[local/]share/gnuradio/examples/digital/, or so). That's a bit more
  advanced than your RX.
 According to my knowledge, the OFDM transceiver blocks I used is the
 latest one. I've read all the related codes so I know that there is
 actually equalization done on the receiver end. Besides, the more advanced
 example you referred to is actually a breaking down of the receiver block
 that I used. In other words, that is the internal implementation of the
 receiver block I used.

 I will try checking the sample values as you suggested. Also, maybe I'll
 also use another USRP to test but I doubt it matters.

 Best,
 Henry


 

 Message: 20
 Date: Thu, 19 Mar 2015 13:37:53 +0100
 From: Marcus M?ller marcus.muel...@ettus.com
 To: discuss-gnuradio@gnu.org
 Subject: Re: [Discuss-gnuradio] OFDM test with USRP
 Message-ID: 550ac321.10...@ettus.com
 Content-Type: text/plain; charset=windows-1252

 Hi Henry,
  I have built a tx and a rx grc flowchart for OFDM using USRP. I found
  the range of the amplitude of the input is fairly small in order to
  get it working (i.e., the USRP at the rx end can successfully decode
  the packets.)  I wound if anyone can share some thoughts about this?
  I've been stuck here for several days.
 there's very many factors limiting the decodability of a transmission --
 the main being SNR, especially since you get problems the further you
 move away, but also aspects like the increased multipath effects, that
 the equalizer might or might not be up to compensate.

 What you're seeing might be something else, though:
  Through my test, I found the const in multiply_const in the tx part
  (which corresponds to amplitude adjustment) needs to be (0.05, 0.025).
 that value definitely has the effect of limiting the sample amplitude
 that goes into your USRP. The USRP driver framework maps values from
 -1;1 to (DAC_min; DAC_max), basically. Driving the USRP with values
 close to (or even over) 1.0 will lead to clipping/gain compression
 problems. However, small values of course lead to weak signal on
 average, leading to low SNR. The OFDM Tx that you use internally uses

[Discuss-gnuradio] OFDM test with USRP

2015-03-18 Thread Henry Jin

Hi everyone,

I have built a tx and a rx grc flowchart for OFDM using USRP. I found the
range of the amplitude of the input is fairly small in order to get it
working (i.e., the USRP at the rx end can successfully decode the packets.)
 I wound if anyone can share some thoughts about this? I've been stuck here
for several days.

To quantify the packet reception performance, I modified digital.crc32_bb
so that even when the crc test fails, the wrong packet is still fed to the
output. In this way, I can evaluate the packet error rate (PER). Through my
test, I found the const in multiply_const in the tx part (which corresponds
to amplitude adjustment) needs to be (0.05, 0.025). In this range, the PER
can be 0. However, when the const value increases, for example, to 0.06.
the PER is around 0.0044. When we further increase the const value to 0.08,
the PER is above 10% or even higher. I guess this is probably because the
input signal amplitude of the USRP needs to be in a certain working range.
However, it seems to me this range is too small. Besides, how can I find
some numerical statistics about the amplitude limitation? On the other
hand, if the amplitude is decreased to 0.02, many packets will be failed to
synchronize. But I do observed that the packets successfully synchronized
are also correctly decoded. In other words, the PER is still 0, but the
number of packets correctly decoded is actually much smaller than the
number of packets sent.

I also tried to enable the two disabled blocks in the files but it is of no
help.

Thanks for any comments.

link:
https://www.dropbox.com/s/ndrtide1g73u5ju/grc_ofdm_rx.grc?dl=0
https://www.dropbox.com/s/8g3kg2tg6pdh0dy/grc_ofdm_tx.grc?dl=0
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] SNR estimation for QAM modulation

2014-01-24 Thread Henry Jin

Hi all,

I'm wondering if SNR estimation by using the probe_mpsk_snr_est_xx can be
applied to QAM modulation as well? I checked the source code and found
nothing specific tied to MPSK modulation. Also, I found Tom has a blog
about SNR estimator years ago
http://www.trondeau.com/grcon12-hackfest/2012/10/1/snr-estimators.html
But it seems the referred grc file has been removed. Can I still get the
files from some repository?

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

Re: [Discuss-gnuradio] About DPSK mod and demod

2014-01-10 Thread Henry Jin

Hi all,

I managed to find out the reason why error rate module cannot work. Just
want to share my thoughts and hopefully it can help other guys when they
want to do similar simulation.

As cited in my previous post below, I tried to evaluate the BER performance
using GRC for DPSK modulation and demodulation. I made a mistake in this
flowgraph since there is no synchronization module. So, we have to add some
training sequence to the stream sent and do a correlation after the
demodulation. In this way, the streams can be synchronized and the bit
error rate can be correctly calculated. Of course, since we have to add
some customized modules, the best way is to directly work on the python
script.

Best
Henry

On Tue, Dec 3, 2013 at 10:00 PM, Henry Jin henry.ji...@gmail.com wrote:

Hi,

I tried to build a simple flow graph of DPSK modulation and demodulation.
The result is verified using the Error Rate module. The link shows the flow
I'm using.

https://www.dropbox.com/s/jwmmttyi4es4alf/Screenshot%20from%202013-12-03%2021%3A50%3A58.png

I know that the output of demod module is unpacked bytes, so an unpacked
to packed module is attached after demodulation. However, the BER is close
to 50%, which surely indicates something wrong. I further analyzed the two
inputs of the Error Rate module by writing info to the file sink. It
clearly shows the discrepancy. So I just wonder what is wrong with this
flow graph. Could someone please help me?

Also, as I noticed, in the output file generated after unpacked to
packed module, there are many consecutive 0s at the start of the file.
Does that indicate something?

Suggestions are greatly appreciated!

On Sat, Dec 14, 2013 at 5:50 PM, Wayne Roberts wroberts92...@gmail.comwrote:

There isnt any QA code for QAM modulator or demodulator.
They do not work for me.
I think if they worked, then their would be QA code.

On Sat, Dec 14, 2013 at 12:08 PM, Henry Jin henry.ji...@gmail.com wrote:

Hi Wayne

I agree with every point you mentioned in your reply. For the variable
Bits per symbol, that was a mistake since I previously used it to test QAM.

So, have you tested QAM? In my test, the two files didn't match as
discussed in my previous post. Just curious about why this mismatch can
happen. Thanks.

Have a good weekend
Henry

On Sat, Dec 14, 2013 at 11:19 AM, Wayne Roberts
wroberts92...@gmail.comwrote:

I i try that DQPSK schema myself, but i notice that in your image you
have Bits per symbol in packet encoder set to 4, but the help of packet
encoder says 2 for DQPSK.

I try 2, and i get no errors until the end, probably because of file
buffering.
--- sent.hex2013-12-14 10:11:41.308775941 -0800
+++ got.hex 2013-12-14 10:11:52.269776677 -0800
@@ -62206,259 +62206,3 @@
00f2fd0: 4db3 ace4 e63f eb53 3fb3 e20a 6cdf 85ab M?.S?...l...
00f2fe0: 1a29 0ae6 3816 2e64 bd37 dc08 6982 379b .)..8..d.7..i.7.
00f2ff0: fd0d 6dc5 0d68 53e9 0384 8234 3af2 9861 ..m..hS4:..a
-00f3000: 1625 7ce9 c0aa 64e6 9272 6ce2 9dce d524 .%|...d..rl$
-00f3010: 1d0f 748e bcfb 88a8 f9ee 3504 1dd4 7204 ..t...5...r.

bytes_sent file has 999424 bytes
and bytes_received has 995328 bytes.
The difference is probably that 1 million samples from random source
isnt even to the payload length of packet encoder.

On Sun, Dec 8, 2013 at 8:57 PM, Henry Jin henry.ji...@gmail.com wrote:

Hi all,

As per previous discussions, I have changed my design as shown in the
link
https://www.dropbox.com/s/8pw27f29qf5unuq/Screenshot%20from%202013-12-08%2021%3A39%3A05.png

This time, QPSK and BPSK both works as I compared the files generated.
However, I found two more problems:
1. When Error Rate module is enabled, the simulation can only be run
for one or two seconds, then it gets stuck. This was observed by attaching
a scope in the flowgraph. The display of the scope is never able to be
updated. Just wonder why this happens?
2. When DPSK Mod and Demod blocks are replaced by QAM Mod and Demod, I
find that many packets are missing in the receiver's decoded file compared
to the file on the sender side. Except the missing packets, all other
packets in the receiver's decoded file can perfectly match with the ones
sent. So what has caused this issue? To make it better understood, I
attached a screenshot comparing the two files from file sinks.

https://www.dropbox.com/s/9203fvigi3wohmh/Screenshot%20from%202013-12-08%2021%3A52%3A48.png

Please give me some suggestions if you have any thoughts. Thanks.
Henry

On Thu, Dec 5, 2013 at 2:39 PM, Henry Jin henry.ji...@gmail.comwrote:

Thanks for your effort in trying to help, Michael. I will continue to
study and if I managed to get it working, I will keep you updated.

Henry

On Thu, Dec 5, 2013 at 2:23 PM, Michael Berman
mrberma...@gmail.comwrote:

Henry,

I looked at this and some of the underlying code, and tried to run
your example with some modifications, but all to no avail

Re: [Discuss-gnuradio] About DPSK mod and demod

2013-12-14 Thread Henry Jin

Hi Wayne

I agree with every point you mentioned in your reply. For the variable Bits
per symbol, that was a mistake since I previously used it to test QAM.

So, have you tested QAM? In my test, the two files didn't match as
discussed in my previous post. Just curious about why this mismatch can
happen. Thanks.

Have a good weekend
Henry

On Sat, Dec 14, 2013 at 11:19 AM, Wayne Roberts wroberts92...@gmail.comwrote:

I i try that DQPSK schema myself, but i notice that in your image you have
Bits per symbol in packet encoder set to 4, but the help of packet encoder
says 2 for DQPSK.

bytes_sent file has 999424 bytes
and bytes_received has 995328 bytes.
The difference is probably that 1 million samples from random source isnt
even to the payload length of packet encoder.

On Sun, Dec 8, 2013 at 8:57 PM, Henry Jin henry.ji...@gmail.com wrote:

Hi all,

As per previous discussions, I have changed my design as shown in the
link
https://www.dropbox.com/s/8pw27f29qf5unuq/Screenshot%20from%202013-12-08%2021%3A39%3A05.png

This time, QPSK and BPSK both works as I compared the files generated.
However, I found two more problems:
1. When Error Rate module is enabled, the simulation can only be run for
one or two seconds, then it gets stuck. This was observed by attaching a
scope in the flowgraph. The display of the scope is never able to be
updated. Just wonder why this happens?
2. When DPSK Mod and Demod blocks are replaced by QAM Mod and Demod, I
find that many packets are missing in the receiver's decoded file compared
to the file on the sender side. Except the missing packets, all other
packets in the receiver's decoded file can perfectly match with the ones
sent. So what has caused this issue? To make it better understood, I
attached a screenshot comparing the two files from file sinks.

https://www.dropbox.com/s/9203fvigi3wohmh/Screenshot%20from%202013-12-08%2021%3A52%3A48.png

Please give me some suggestions if you have any thoughts. Thanks.
Henry

On Thu, Dec 5, 2013 at 2:39 PM, Henry Jin henry.ji...@gmail.com wrote:

Thanks for your effort in trying to help, Michael. I will continue to
study and if I managed to get it working, I will keep you updated.

Henry

On Thu, Dec 5, 2013 at 2:23 PM, Michael Berman mrberma...@gmail.comwrote:

Henry,

I looked at this and some of the underlying code, and tried to run your
example with some modifications, but all to no avail as to what you are
attempting to do. Last time I did anything like this I ended up using the
mod_pkts code (found in gr-digital/python/digital/pkt.py). Maybe there is
some insight in there that may shed light on what you are trying to do.
Sorry I couldn't be of more help.

Michael

On Wed, Dec 4, 2013 at 1:31 PM, Henry Jin henry.ji...@gmail.comwrote:

On Wed, Dec 4, 2013 at 12:13 PM, Michael Berman mrberma...@gmail.com
wrote:

Looking at your flowchart in the original post, you have an Unpacked
to Packed block after the demodulator, with bit's per symbol of 1. This
doesn't seem right to me. I have never tried this with a random source
like you have it setup, however there should be an Unpacked to Packed
block
prior to the modulator and a Packed to Unpacked block after the
demodulator. These should also have bits per chunck values that
correspond
with the bits per symbol of the modulator and demodulator. You need to
feed in the data in a chunk with the correct amount of bits that
correspond
to the bits per symbol of the modulation scheme being used. In the
example, it looks like you are using QPSK, and therefore the bits per
chunk
should be 2 (which is log2(number of constellation points)). The
modulator
and demodulator work with chunks of data where each chuck corresponds to
a
symbol.

*If not using the random source, what other sources do you think it's
better? I know GLFSR source also perfectly fits into this scenario. You
also mentioned I have to attach a Unpacked to Packed block prior to the
modulator. But since in my flow, I already set the random source with
maximum being 256. That means it's already outputting packed bytes. Thus,
IMO, Unpacked to Packed block is not needed based on my settings. The
reason I set the Bits per Chunk value as 1 in the Unpacked to Packed block
after demodulation is that I notice in the source code, it says the output
of the demodulation block is unpacked byte with only one

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) martin.br...@kit.edu

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

[Discuss-gnuradio] Bit error rate test

2013-12-11 Thread Henry Jin

Hi

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?

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

Re: [Discuss-gnuradio] About DPSK mod and demod

2013-12-08 Thread Henry Jin

Hi all,

As per previous discussions, I have changed my design as shown in the link
https://www.dropbox.com/s/8pw27f29qf5unuq/Screenshot%20from%202013-12-08%2021%3A39%3A05.png

This time, QPSK and BPSK both works as I compared the files generated.
However, I found two more problems:
1. When Error Rate module is enabled, the simulation can only be run for
one or two seconds, then it gets stuck. This was observed by attaching a
scope in the flowgraph. The display of the scope is never able to be
updated. Just wonder why this happens?
2. When DPSK Mod and Demod blocks are replaced by QAM Mod and Demod, I find
that many packets are missing in the receiver's decoded file compared to
the file on the sender side. Except the missing packets, all other packets
in the receiver's decoded file can perfectly match with the ones sent. So
what has caused this issue? To make it better understood, I attached a
screenshot comparing the two files from file sinks.
https://www.dropbox.com/s/9203fvigi3wohmh/Screenshot%20from%202013-12-08%2021%3A52%3A48.png

Please give me some suggestions if you have any thoughts. Thanks.
Henry

On Thu, Dec 5, 2013 at 2:39 PM, Henry Jin henry.ji...@gmail.com wrote:

Thanks for your effort in trying to help, Michael. I will continue to
study and if I managed to get it working, I will keep you updated.

Henry

On Thu, Dec 5, 2013 at 2:23 PM, Michael Berman mrberma...@gmail.comwrote:

Henry,

Michael

On Wed, Dec 4, 2013 at 1:31 PM, Henry Jin henry.ji...@gmail.com wrote:

On Wed, Dec 4, 2013 at 12:13 PM, Michael Berman mrberma...@gmail.com
wrote:

Looking at your flowchart in the original post, you have an Unpacked to
Packed block after the demodulator, with bit's per symbol of 1. This
doesn't seem right to me. I have never tried this with a random source
like you have it setup, however there should be an Unpacked to Packed block
prior to the modulator and a Packed to Unpacked block after the
demodulator. These should also have bits per chunck values that correspond
with the bits per symbol of the modulator and demodulator. You need to
feed in the data in a chunk with the correct amount of bits that correspond
to the bits per symbol of the modulation scheme being used. In the
example, it looks like you are using QPSK, and therefore the bits per chunk
should be 2 (which is log2(number of constellation points)). The modulator
and demodulator work with chunks of data where each chuck corresponds to a
symbol.

For the Samples per Symbol, if I were transmitting over the air, I
would raise this value to a little bit more than 2, just to ensure the
receiver can lock onto the changes with given noise before the symbol
changes again. In this case of looping the modulator strait into the
demodulator, this should work fine.

*Thanks for the advice, I will take it. *

One more thing I would look at would be the Error Rate block source. I
have never used this block, but in my thinking about it in this flowchart,
I would source it from the throttle instead of the random source. This may
help with keeping the data a little more somewhat aligned.

*Yes, this could make things clearer. But maybe it makes no difference.
I remember in one of Tom's tutorial, he said as long as there is one
throttle in the flow, then all the units are throttled.*

Michael

On Wed, Dec 4, 2013 at 9:52 AM, Henry Jin henry.ji...@gmail.comwrote:

I tried again replacing the DPSK module with PSK module. Still cannot
get the correct data. The parameter for Error Rate Bits per Symbol is
changed to 8 since every bit carries information in my flow. The sizes of
the files from the two file sinks are exactly the same, except with
different data.

On Tue, Dec 3, 2013 at 10:11 PM, Nick Foster bistrom...@gmail.comwrote:

Can you try using

Re: [Discuss-gnuradio] About DPSK mod and demod

2013-12-05 Thread Henry Jin

Thanks for your effort in trying to help, Michael. I will continue to study
and if I managed to get it working, I will keep you updated.

Henry

On Thu, Dec 5, 2013 at 2:23 PM, Michael Berman mrberma...@gmail.com wrote:

Henry,

Michael

On Wed, Dec 4, 2013 at 1:31 PM, Henry Jin henry.ji...@gmail.com wrote:

On Wed, Dec 4, 2013 at 12:13 PM, Michael Berman mrberma...@gmail.com
wrote:

Looking at your flowchart in the original post, you have an Unpacked to
Packed block after the demodulator, with bit's per symbol of 1. This
doesn't seem right to me. I have never tried this with a random source
like you have it setup, however there should be an Unpacked to Packed block
prior to the modulator and a Packed to Unpacked block after the
demodulator. These should also have bits per chunck values that correspond
with the bits per symbol of the modulator and demodulator. You need to
feed in the data in a chunk with the correct amount of bits that correspond
to the bits per symbol of the modulation scheme being used. In the
example, it looks like you are using QPSK, and therefore the bits per chunk
should be 2 (which is log2(number of constellation points)). The modulator
and demodulator work with chunks of data where each chuck corresponds to a
symbol.

For the Samples per Symbol, if I were transmitting over the air, I would
raise this value to a little bit more than 2, just to ensure the receiver
can lock onto the changes with given noise before the symbol changes again.
In this case of looping the modulator strait into the demodulator, this
should work fine.

*Thanks for the advice, I will take it. *

*Yes, this could make things clearer. But maybe it makes no difference. I
remember in one of Tom's tutorial, he said as long as there is one throttle
in the flow, then all the units are throttled.*

Michael

On Wed, Dec 4, 2013 at 9:52 AM, Henry Jin henry.ji...@gmail.com wrote:

On Tue, Dec 3, 2013 at 10:11 PM, Nick Foster bistrom...@gmail.comwrote:

Can you try using the PSK mod/demod blocks with differential=Yes
instead of the DPSK mod/demod blocks? I found an issue today with the DPSK
mod/demod blocks which results in them not actually using differential
encoding.

--n

On Tue, Dec 3, 2013 at 9:00 PM, Henry Jin henry.ji...@gmail.comwrote:

Hi,

I tried to build a simple flow graph of DPSK modulation and
demodulation. The result is verified using the Error Rate module. The
link
shows the flow I'm using.

https://www.dropbox.com/s/jwmmttyi4es4alf/Screenshot%20from%202013-12-03%2021%3A50%3A58.png

I know that the output of demod module is unpacked bytes, so an
unpacked to packed module is attached after demodulation. However, the
BER is close to 50%, which surely indicates something wrong. I further
analyzed the two inputs of the Error Rate module by writing info to the
file sink. It clearly shows the discrepancy. So I just wonder what is
wrong
with this flow graph. Could someone please help me?

Also, as I noticed, in the output file generated after unpacked to
packed module, there are many consecutive 0s at the start of the file.
Does that indicate something?

Suggestions are greatly appreciated!

Henry

Re: [Discuss-gnuradio] About DPSK mod and demod

2013-12-04 Thread Henry Jin

I tried again replacing the DPSK module with PSK module. Still cannot get
the correct data. The parameter for Error Rate Bits per Symbol is changed
to 8 since every bit carries information in my flow. The sizes of the files
from the two file sinks are exactly the same, except with different data.

On Tue, Dec 3, 2013 at 10:11 PM, Nick Foster bistrom...@gmail.com wrote:

Can you try using the PSK mod/demod blocks with differential=Yes instead
of the DPSK mod/demod blocks? I found an issue today with the DPSK
mod/demod blocks which results in them not actually using differential
encoding.

--n

On Tue, Dec 3, 2013 at 9:00 PM, Henry Jin henry.ji...@gmail.com wrote:

Hi,

I tried to build a simple flow graph of DPSK modulation and demodulation.
The result is verified using the Error Rate module. The link shows the flow
I'm using.

https://www.dropbox.com/s/jwmmttyi4es4alf/Screenshot%20from%202013-12-03%2021%3A50%3A58.png

Also, as I noticed, in the output file generated after unpacked to
packed module, there are many consecutive 0s at the start of the file.
Does that indicate something?

Suggestions are greatly appreciated!

Henry

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

Re: [Discuss-gnuradio] About DPSK mod and demod

2013-12-04 Thread Henry Jin

On Wed, Dec 4, 2013 at 12:13 PM, Michael Berman mrberma...@gmail.com
wrote:

Looking at your flowchart in the original post, you have an Unpacked to
Packed block after the demodulator, with bit's per symbol of 1. This
doesn't seem right to me. I have never tried this with a random source
like you have it setup, however there should be an Unpacked to Packed block
prior to the modulator and a Packed to Unpacked block after the
demodulator. These should also have bits per chunck values that correspond
with the bits per symbol of the modulator and demodulator. You need to
feed in the data in a chunk with the correct amount of bits that correspond
to the bits per symbol of the modulation scheme being used. In the
example, it looks like you are using QPSK, and therefore the bits per chunk
should be 2 (which is log2(number of constellation points)). The modulator
and demodulator work with chunks of data where each chuck corresponds to a
symbol.

For the Samples per Symbol, if I were transmitting over the air, I would
raise this value to a little bit more than 2, just to ensure the receiver
can lock onto the changes with given noise before the symbol changes again.
In this case of looping the modulator strait into the demodulator, this
should work fine.

*Thanks for the advice, I will take it. *

*Yes, this could make things clearer. But maybe it makes no difference. I
remember in one of Tom's tutorial, he said as long as there is one throttle
in the flow, then all the units are throttled.*

Michael

On Wed, Dec 4, 2013 at 9:52 AM, Henry Jin henry.ji...@gmail.com wrote:

I tried again replacing the DPSK module with PSK module. Still cannot get
the correct data. The parameter for Error Rate Bits per Symbol is changed
to 8 since every bit carries information in my flow. The sizes of the files
from the two file sinks are exactly the same, except with different data.

On Tue, Dec 3, 2013 at 10:11 PM, Nick Foster bistrom...@gmail.comwrote:

Can you try using the PSK mod/demod blocks with differential=Yes instead
of the DPSK mod/demod blocks? I found an issue today with the DPSK
mod/demod blocks which results in them not actually using differential
encoding.

--n

On Tue, Dec 3, 2013 at 9:00 PM, Henry Jin henry.ji...@gmail.com wrote:

Hi,

I tried to build a simple flow graph of DPSK modulation and
demodulation. The result is verified using the Error Rate module. The link
shows the flow I'm using.

https://www.dropbox.com/s/jwmmttyi4es4alf/Screenshot%20from%202013-12-03%2021%3A50%3A58.png

I know that the output of demod module is unpacked bytes, so an
unpacked to packed module is attached after demodulation. However, the
BER is close to 50%, which surely indicates something wrong. I further
analyzed the two inputs of the Error Rate module by writing info to the
file sink. It clearly shows the discrepancy. So I just wonder what is wrong
with this flow graph. Could someone please help me?

Also, as I noticed, in the output file generated after unpacked to
packed module, there are many consecutive 0s at the start of the file.
Does that indicate something?

Suggestions are greatly appreciated!

Henry

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

[Discuss-gnuradio] About DPSK mod and demod

2013-12-03 Thread Henry Jin

Hi,

I tried to build a simple flow graph of DPSK modulation and demodulation.
The result is verified using the Error Rate module. The link shows the flow
I'm using.

https://www.dropbox.com/s/jwmmttyi4es4alf/Screenshot%20from%202013-12-03%2021%3A50%3A58.png

I know that the output of demod module is unpacked bytes, so an unpacked
to packed module is attached after demodulation. However, the BER is close
to 50%, which surely indicates something wrong. I further analyzed the two
inputs of the Error Rate module by writing info to the file sink. It
clearly shows the discrepancy. So I just wonder what is wrong with this
flow graph. Could someone please help me?

Also, as I noticed, in the output file generated after unpacked to packed
module, there are many consecutive 0s at the start of the file. Does that
indicate something?

Suggestions are greatly appreciated!

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

Re: [Discuss-gnuradio] benchmark_rx.py segmentation fault

Re: [Discuss-gnuradio] OFDM test with USRP

Re: [Discuss-gnuradio] OFDM test with USRP

Re: [Discuss-gnuradio] OFDM test with USRP

[Discuss-gnuradio] OFDM test with USRP

[Discuss-gnuradio] SNR estimation for QAM modulation

Re: [Discuss-gnuradio] About DPSK mod and demod

Re: [Discuss-gnuradio] About DPSK mod and demod

Re: [Discuss-gnuradio] Bit error rate test

[Discuss-gnuradio] Bit error rate test

Re: [Discuss-gnuradio] About DPSK mod and demod

Re: [Discuss-gnuradio] About DPSK mod and demod

Re: [Discuss-gnuradio] About DPSK mod and demod

Re: [Discuss-gnuradio] About DPSK mod and demod

[Discuss-gnuradio] About DPSK mod and demod

15 matches

Site Navigation

Mail list logo

Footer information