|
From: | Rama V |
Subject: | Re: [Discuss-gnuradio] Fwd: Re: Transmission error |
Date: | Sun, 4 Oct 2015 18:14:57 -0500 |
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 youRegards,DaveOn Thu, Oct 1, 2015 at 5:49 AM, Marcus Müller <address@hidden> 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 250000Receiver: ./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 <address@hidden> 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 <address@hidden> 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:
DaveRegards,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
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.
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
On Mon, Sep 21, 2015 at 11:00 AM, Rama V <address@hidden> 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 <address@hidden> 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 250kThat'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.
Receiver : benchmark_rx.py -f 2.435G
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.435GBut 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,
DaveOn Sep 18, 2015 2:21 PM, "Rama V" <address@hidden> 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 <address@hidden> 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 address@hidden https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Prev in Thread] | Current Thread | [Next in Thread] |