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