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 <mailto: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 <mailto: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 <mailto: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 >>>> <mailto:marcus.muel...@ettus.com>> wrote: >>>> >>>> Hi, >>>> >>>> On 21.03.2016 01 <tel: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 >>>> <mailto:Discuss-gnuradio@gnu.org> >>>> 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/>www.mhe-krg.org >>>> <http://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 >>> <http://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 <http://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 <http://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
