Hey all, The problem has been solved. I have just mentioned the -a (args) for the serial number. That's it. Thanks
Regards, Dave On Sun, Oct 4, 2015 at 5:49 PM, Rama V <ramav...@gmail.com> wrote: > Thanks for the reply Marcus. I apologize for having asking these many > times. Now I understand the transmission probability of the data packets in > the real world. I have 4 USRP's that I am testing on , these benchmark > scripts. I want to send the information from 1st USRP to 3rd USRP. Do I > need to mention any serial number or antenna of the USRP? I tried the > --help command but it didn't have much information about that. I have > checked several GNU Radio sites but I did not find this information > anywhere. I have no knowledge regarding this thing. > Thank you > > Regards, > Dave > > On Thu, Oct 1, 2015 at 5:49 AM, Marcus Müller <marcus.muel...@ettus.com> > wrote: > >> 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 >> > 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>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> >>>> 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>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> >>>>>> 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> >>>>>> 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>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 >>>>>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>>> >>>>>> >>>>> >>>> >>>> >>> >>> >> >> >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
