Marcus, many thanks I will do it. On Mon, Mar 21, 2016 at 11:01 AM, Marcus Müller <marcus.muel...@ettus.com> wrote:
> I'd encourage you to either fix the Bit Error Rate block or write > something that does your job. In fact, the unmodified ofdm_loopback example > doesn't work as BER test, because all packets are identical, and if a > packet has errors, the OFDM receiver will drop it, so you'd never see an > error. > > Open rx_ofdm.grc ; it is a very similar example, but instead of having the > black box "OFDM Receiver", you see how the OFDM receiver internally works. > Play with the channel model; e.g. set the noise voltage really high (1.0) > and the frequency offset to e.g. 2.0/fft_len. You'll see a lot of > > INFO: Detected and invalid packet at item .... > > printed. > Now, change these parameters. > Your ratio of valid packets and invalid packets gives you a packet error > rate. > > Best regards, > Marcus > > > On 21.03.2016 11:47, Diyar Muhammed wrote: > > Marcus, > I look at ofdm_loopback.grc example, I made the same scenario but I had > problem with Error Rate block I got error rate around 4 to 5, as my > knowledge that is not right I think should be between 0 to 1. > If there is a transceiver example with measure bit error rate that will be > helpful for me. > in advance thank you. > > On Mon, Mar 21, 2016 at 10:36 AM, Marcus Müller <marcus.muel...@ettus.com> > wrote: > >> Note that the benchmark_rx/_tx example is really a bit old, and I always >> try to steer people away from it towards the newer OFDM examples that are >> far more flexible and behave a lot more like a real system would. >> >> Have a look at the ofdm_loopback.grc example; you can replace the >> (channelmodel->throttle) by a USRP sink and source. Tadah! Live demo. >> >> Best regards, >> Marcus >> >> >> On 21.03.2016 11:34, Diyar Muhammed wrote: >> >> many thanks >> >> On Mon, Mar 21, 2016 at 10:31 AM, Marcus Müller < >> <marcus.muel...@ettus.com>marcus.muel...@ettus.com> wrote: >> >>> Diyar, >>> >>> > I look at tx benchmark help I could not find rates but there is packet >>> size and megabytes to transmit. >>> >>> benchmark_tx --help should help you. >>> You set the bandwidth, which sets the sampling rate; together with the >>> occupied tones number related to the FFT length, you get a symbol rate. >>> Together with the modulation you set, this gives you a >>> >>> Since only one program can use a USRP at a time, you can't use >>> benchmark_tx and benchmark_rx at the same time. >>> Instead, use benchmark_tx with the "--to-file" option to save the >>> samples to a file, and build a quick GNU Radio flow graph in GRC that has a >>> file source (reading that file), a USRP sink (fed from the file source), a >>> USRP source, and a file sink (saving the samples from the USRP source to >>> another file). >>> >>> Then use benchmark_rx with the --from-file option to read in these saved >>> samples. >>> >>> Best regards, >>> Marcus >>> >>> >>> On 21.03.2016 11:17, Diyar Muhammed wrote: >>> >>> Dear Marcus, >>> Thank you very much indeed for fast replying. >>> I look at tx benchmark help I could not find rates but there is packet >>> size and megabytes to transmit. >>> so that, which one do you mean packet size or megabytes? >>> it is okay to use USRP B210 for transmitting and receiving by using to >>> benchmark file? >>> because when I used one of them (tx or rx) and then I wanted to run >>> another one the error come up (no device found for empty device address). >>> in advance many thanks. >>> >>> On Mon, Mar 21, 2016 at 9:57 AM, Marcus Müller < >>> <marcus.muel...@ettus.com>marcus.muel...@ettus.com> wrote: >>> >>>> Diyar, >>>> >>>> with the benchmark_ scripts, you **set** the rates, and you can only >>>> observe how many packets were successfully transmitted. >>>> The rest is really very basic math. >>>> >>>> Best regards, >>>> Marcus >>>> >>>> >>>> On 21.03.2016 10:50, Diyar Muhammed wrote: >>>> >>>> Dear SangHyuk, >>>> I would like to know how to measure Throughput and BER by using >>>> benchmark tx and rx? >>>> could you show or explain with real example as you used. >>>> in advance thanks. >>>> >>>> On Mon, Mar 21, 2016 at 8:09 AM, Marcus Müller < >>>> <marcus.muel...@ettus.com>marcus.muel...@ettus.com> wrote: >>>> >>>>> Hi, >>>>> >>>>> On 21.03.2016 01 <21.03.2016%2001>:37, SangHyuk Kim wrote: >>>>> > I want to know other user's performance (avg performance). >>>>> Yes, but what is "user's performance"? Is it more important to have >>>>> higher throughput, or lower error rates? What about robustness? >>>>> >>>>> I mean, the OFDM rx_benchmark is a really static example. >>>>> You might find a setting that maximizes troughput for a given channel, >>>>> but imagine something happens that reduces your receiver's SNR by 3dB: >>>>> Now your suddenly losing a lot of performance. >>>>> >>>>> Really "how can I parameterize this" can only be answered for a single, >>>>> mathematically well-defined target, and for a well-defined channel. >>>>> >>>>> In a real-world scenario, if using a transceiver with a fixed >>>>> modulation, you usually wouldn't maximize throughput for a given >>>>> setting, but you would define what "it still works sufficiently" means, >>>>> and then you'd define "the worst channel I want the system to still >>>>> work >>>>> sufficiently". >>>>> Then you'd come up with a metric that gives you a number for "the link >>>>> quality on all considerable channels where this should be working", and >>>>> then you'd try to maximize that metric under the outage constraints set >>>>> before. Notice that this metric has to take things like error rate, >>>>> throughtput, the "cost" of re-sending something (if you have a >>>>> mechanism >>>>> for that), available channel coding, how much you care about latency, >>>>> computational complexity (that really gets important with iterative >>>>> channel decoding), >>>>> >>>>> In other words: >>>>> This is digital communications. If there was a single "best" solution, >>>>> we'd all be using that and be done. Use your digital communications >>>>> knowledge to analyze your requirements and challenges! >>>>> >>>>> Best regards >>>>> Marcus >>>>> >>>>> _______________________________________________ >>>>> Discuss-gnuradio mailing list >>>>> <Discuss-gnuradio@gnu.org>Discuss-gnuradio@gnu.org >>>>> <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio> >>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>> >>>> >>>> >>>> >>>> -- >>>> Regards, >>>> Diyar Muhammed >>>> Ministry of Higher Education and Scientific Research >>>> Duty: Network Administration and Design >>>> Website: <http://www.mhe-krg.org/> <http://www.mhe-krg.org> >>>> www.mhe-krg.org >>>> Cell Phone: 009647504690060 >>>> Office Phone: 00964662554683 >>>> >>>> >>>> >>> >>> >>> -- >>> Regards, >>> Diyar Muhammed >>> Ministry of Higher Education and Scientific Research >>> Duty: Network Administration and Design >>> Website: <http://www.mhe-krg.org/> <http://www.mhe-krg.org> >>> www.mhe-krg.org >>> Cell Phone: 009647504690060 >>> Office Phone: 00964662554683 >>> >>> >>> >> >> >> -- >> Regards, >> Diyar Muhammed >> Ministry of Higher Education and Scientific Research >> Duty: Network Administration and Design >> Website: <http://www.mhe-krg.org/>www.mhe-krg.org >> Cell Phone: 009647504690060 >> Office Phone: 00964662554683 >> >> >> > > > -- > Regards, > Diyar Muhammed > Ministry of Higher Education and Scientific Research > Duty: Network Administration and Design > Website: www.mhe-krg.org > Cell Phone: 009647504690060 > Office Phone: 00964662554683 > > > -- Regards, Diyar Muhammed Ministry of Higher Education and Scientific Research Duty: Network Administration and Design Website: www.mhe-krg.org Cell Phone: 009647504690060 Office Phone: 00964662554683
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
