Dave, you've been told this *several times* now:
This is Radio communication. Every radio transmission has a certain probability of going right or wrong. You will never ever have a 0% bit error rate system under real world influences. It is *not* an indication of something being wrong when some packets are not ok=true. You need to understand that, really. You should brush up your theoretical basis; get a textbook, read up on "noise", "AWGN", the "binary channel model", and lastly, when you really understand all these concepts "channel capacity". You will realize that in every environment, each symbol transfered over the air will have a non-zero probability of being flipped. By improving the transmission parameters, you can reduce that symbol error probability, but you cannot reduce it to 0. Each packet contains a lot of bits of info, meaning that to get a successful packet transmission, each of the many symbols that make up that packet need to be correctly received; that is a very classical probability; for a memoryless channel, the probability that a packet is being transmitted without a single symbol error is relatively simple to calculate. I don't mean to be rude, but: You're wasting your (and our) time always asking "can somebody help me improve what I do with these ready-to-use scripts"; you will need to _understand_ at least roughly what you're doing; there's no way around that. I think these "how to use benchmark_tx/rx" threads have gone and I shall give them a bit of rest now. Best regards, Marcus On 30.09.2015 18:44, Rama V wrote: > Hey all, > Thanks for the help. Now I am able to receive all the packets to be > "ok=true" because of the USRP's being kept near.. The commands that I > have set from the /digital/narrowband folder are > > Sender: ./benchmark_tx.py -p 4 -M 2 -f 2.435000061G --tx-gain=28 -r 250000 > Receiver: ./benchmark_rx.py -p 4 -f 2.435000061G --rx-gain=53 -r 250000 > > I guess all this works because of the position of antenna placing it > in a right way. But when I place them apart, for a farther distance, I > have a packet loss of 150-200. I guess that's because of interference > in the environment. Is there anything I can do to reduce those? Also, > I wanted to do the same experiment by placing 2 more USRP and sending > data to the receiver from different transmitter. Can anyone kindly > help me with that issue?. Thanks. Please excuse me if I am not being > informative. > > Regards, > Dave > > On Fri, Sep 25, 2015 at 11:44 AM, Marcus Müller > <marcus.muel...@ettus.com <mailto:marcus.muel...@ettus.com>> wrote: > > Hi Dave, > > obviously 95% success means a 5% packet error rate. That sounds > pretty physically sound -- for most constellations, you can > calculate the symbol error rate from the SNR, and from the symbol > error rate it's a matter of combinatorics to derive the lower > boundary for packet error rate. > Again, this is wireless communication. It's not a "works > perfectly/works not at all" world, but a "works stochastically" > world. 5% packet error rate might or might not be acceptable, > depending on a specific application. > > Best regards, > Marcus > > > On 09/25/2015 12:07 AM, Rama V wrote: >> Hi all, >> I have tried to send packets to the receiver from >> /digital/narrowband folder and it has mostly succeeded. The >> output I was able to get when I sent the following commands were >> >> Sender: ./benchmark_tx.py -p 4 -M 2 -f 2.435000061G --tx-gain=28 >> -r 250000 >> Receiver: ./benchmark_rx.py -p 4 -f 2.435000061G --rx-gain=54 -r >> 250000 >> >> ok = True pktno = 1323 n_rcvd = 1303 n_right = 1294 >> ok = True pktno = 1324 n_rcvd = 1304 n_right = 1295 >> ok = True pktno = 1325 n_rcvd = 1305 n_right = 1296 >> ok = True pktno = 1326 n_rcvd = 1306 n_right = 1297 >> ok = True pktno = 1327 n_rcvd = 1307 n_right = 1298 >> ok = True pktno = 1328 n_rcvd = 1308 n_right = 1299 >> ok = True pktno = 1329 n_rcvd = 1309 n_right = 1300 >> ok = True pktno = 1330 n_rcvd = 1310 n_right = 1301 >> ok = False pktno = 1331 n_rcvd = 1311 n_right = 1301 >> >> But there were a few packets where I have not received them >> correctly. I guess only 95% of them were efficient in >> transmitting. I have tried changing the gain settings and what I >> observed was that if I decrease the gain from its normal value, >> the reception of packets are somewhat less efficient. Can I >> kindly know what I might be able to do in order to receive those >> packets in a more efficient way or is that what generally happens >> in a real world transmission? Thanks >> >> Regards, >> Dave >> >> On Tue, Sep 22, 2015 at 1:02 PM, Marcus Müller >> <marcus.muel...@ettus.com <mailto:marcus.muel...@ettus.com>> wrote: >> >> Ok, >>> This is because I have changed my folder to /digital/ofdm, I >>> have started to receive packets. >> this means that you're using something *completely* different >> than before. It's simply a completely different transceiver >> system. >>> kindly advise if I need to figure out the combination >>> settings till most of them receive properly? >> Yes. You will need to figure out the optimum settings. >> Increase gain on the RX end, see if things get better or >> worse. Find an optimum for that. Do the same with the TX gain. >>> Because even though I did not set any sample rate, the >>> transmitter sent the information. >> As mentioned before multiple times: run the programs with >> "--help". They will show you what default settings they have. >> >>> Please help. Please excuse me if I am being naive in asking >>> these. >> It's alright to ask questions, but please remember to apply >> the things we tell you. >> >> Best regards, >> Marucs >> >> >> On 22.09.2015 00:59, Rama V wrote: >>> Hi, >>> As advised, the problem has been solved to a little extent >>> where I have got the below results by giving the commands as >>> >>> Sender : ./benchmark_tx.py -f 2.435G --tx-gain=25 >>> Receiver: ./benchmark_rx.py -f 2.435G --rx-gain 50 >>> >>> ok: True pktno: 1971 n_rcvd: 1687 n_right: 358 >>> ok: False pktno: 1972 n_rcvd: 1688 n_right: 358 >>> ok: False pktno: 1973 n_rcvd: 1689 n_right: 358 >>> ok: False pktno: 1974 n_rcvd: 1690 n_right: 358 >>> ok: True pktno: 1975 n_rcvd: 1691 n_right: 359 >>> ok: False pktno: 1976 n_rcvd: 1692 n_right: 359 >>> ok: True pktno: 1977 n_rcvd: 1693 n_right: 360 >>> ok: False pktno: 1978 n_rcvd: 1694 n_right: 360 >>> ok: True pktno: 1979 n_rcvd: 1695 n_right: 361 >>> ok: True pktno: 1980 n_rcvd: 1696 n_right: 362 >>> ok: False pktno: 1981 n_rcvd: 1697 n_right: 362 >>> ok: True pktno: 1982 n_rcvd: 1698 n_right: 363 >>> ok: False pktno: 1983 n_rcvd: 1699 n_right: 363 >>> ok: True pktno: 1984 n_rcvd: 1700 n_right: 364 >>> ok: False pktno: 1985 n_rcvd: 1701 n_right: 364 >>> ok: True pktno: 1986 n_rcvd: 1702 n_right: 365 >>> ok: False pktno: 1987 n_rcvd: 1703 n_right: 365 >>> ok: True pktno: 1988 n_rcvd: 1704 n_right: 366 >>> >>> This is because I have changed my folder to /digital/ofdm, I >>> have started to receive packets. But I guess this is only >>> 50% efficient in receiving packets. Not all of them have >>> been receiving properly. kindly advise if I need to figure >>> out the combination settings till most of them receive >>> properly? Because even though I did not set any sample rate, >>> the transmitter sent the information. Please help. Please >>> excuse me if I am being naive in asking these. >>> >>> Regards, >>> Dave >>> >>> On Mon, Sep 21, 2015 at 11:00 AM, Rama V <ramav...@gmail.com >>> <mailto:ramav...@gmail.com>> wrote: >>> >>> Hi, >>> Thanks Marcus. I will do as you have advised and >>> approach if any uncertainties. >>> >>> Regards, >>> Dave >>> >>> On Mon, Sep 21, 2015 at 10:16 AM, Marcus Müller >>> <marcus.muel...@ettus.com >>> <mailto:marcus.muel...@ettus.com>> wrote: >>> >>> Hi Dave, >>> >>> you shouldn't be modifying the python files before >>> you understand what they do exactly. Please revert >>> your edits, because it will be impossible to help >>> you if you don't use the same scripts as we do, >>> obviously. We've talked about this[1]. >>> >>> So: >>>> Sender : benchmark_tx.py -f 2.435G -r 250k >>>> Receiver : benchmark_rx.py -f 2.435G >>> That's wrong! Now, your transmitter sends 250,000 >>> bits per second, but your receiver expects 100.000 >>> (the default value, which doesn't work with your >>> hardware), so that's not good. Use the same setting >>> for both benchmark_tx and benchmark_rx. >>> >>>> So all you say is I need to change and play with >>>> the sampling rates and --tx-amplitude until the >>>> received packet becomes 'n_rcvd=1' >>> No. RF is not "hey, there's this correct setting, >>> let's apply it everywhere"; you'll have to figure >>> out which combination settings work best. Generally, >>> I'd leave the --tx-amplitude untouched, because >>> 0.25 is a sane value for the digital samples; what >>> you want is analog gain, not digital scaling. >>> >>> You should really set a TX gain and a RX gain. Try >>> around with a few different gain settings for RX and >>> TX gain -- a good approach would be to set something >>> like 25 dB TX gain, and around 50 dB RX gain, if you >>> place your TX and RX antennas far enough from each >>> other. Notice that I'm assuming you're using >>> antennas, and no direct connection! If you're using >>> a direct cable between TX and RX, please use an >>> attenuator, because you might otherwise damage your >>> hardware. >>> >>> To find out how to change the gains, please read the >>> output of >>> benchmark_tx.py --help >>> and of >>> benchmark_rx.py --help >>> >>> >>> Best regards, >>> Marcus >>> >>> >>> [1] >>> >>> http://lists.gnu.org/archive/html/discuss-gnuradio/2015-09/msg00124.html >>> >>> >>> On 21.09.2015 16:48, Rama V wrote: >>>> >>>> I have tried the following commands in the terminal >>>> >>>> Sender : benchmark_tx.py -f 2.435G -r 250k >>>> Receiver : benchmark_rx.py -f 2.435G >>>> >>>> But the data packets are not being sent correctly. >>>> I have been receiving the packets as ok=false. I >>>> have tried modifying benchmark python scripts. Can >>>> I do the modification of those scripts or evrything >>>> needs to be given in the command line. Please >>>> excuse me as I am slightly unable to understand. Thanks >>>> >>>> Regards, >>>> Dave >>>> >>>> On Sep 18, 2015 2:21 PM, "Rama V" >>>> <ramav...@gmail.com <mailto:ramav...@gmail.com>> wrote: >>>> >>>> Thanks for the reply Michael. I will look into >>>> that as you have advised. So all you say is I >>>> need to change and play with the sampling rates >>>> and --tx-amplitude until the received packet >>>> becomes 'n_rcvd=1' and CRC check changes to >>>> 'ok=true' from the narrowband folder? >>>> >>>> Regards, >>>> Dave >>>> >>>> On Fri, Sep 18, 2015 at 12:40 PM, Michael >>>> Dickens <michael.dick...@ettus.com >>>> <mailto:michael.dick...@ettus.com>> wrote: >>>> >>>> Hi Dave - I'm thinking that you are >>>> confusing "--samples-per-symbol" for the >>>> sample rate. I think the option you're >>>> looking for is "-r". Look at the "--help" >>>> for those examples when you get a chance. - MLD >>>> >>>> On Thu, Sep 17, 2015, at 02:01 PM, Rama V >>>> wrote: >>>>> >>>>> Thank you very much Michael. I will follow >>>>> up on your advice. I am sorry that I >>>>> wasn't able to understand some parts in >>>>> GNU RADIO and didn't specify enough >>>>> information. Regarding the question, I >>>>> have been doing the benchmark in the >>>>> digital/ narrowband/ folder. The exact >>>>> commands I have been working on are >>>>> >>>>> Sender: benchmark_tx.py -f 2.435G >>>>> --tx-gain 25 --samples-per-symbol 250000 >>>>> >>>>> Receiver: benchmark_rx.py -f 2.435G >>>>> >>>>> When I give 250kS/s, my laptop freezes. >>>>> USRP is XCVR2450. So I started to give >>>>> less Samples like 50kS/s so that they >>>>> communicate with each other without >>>>> errors. But I couldn't figure out the >>>>> solution to that. So I just have a doubt >>>>> whether I need to modify benchmark scripts >>>>> or is it enough for the parameters I give >>>>> in the command line. Thanks for the help. >>>>> Please advice >>>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Discuss-gnuradio mailing list >>>> Discuss-gnuradio@gnu.org >>>> <mailto:Discuss-gnuradio@gnu.org> >>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> >>> _______________________________________________ >>> Discuss-gnuradio mailing list >>> Discuss-gnuradio@gnu.org >>> <mailto: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
