Re: [Discuss-gnuradio] Fwd: Re: Transmission error

[Rama V]

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 
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.43561G --tx-gain=28 -r 25
> Receiver: ./benchmark_rx.py -p 4 -f 2.43561G --rx-gain=53 -r 25
>
> 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 
> 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.43561G --tx-gain=28 -r 25
>> Receiver: ./benchmark_rx.py -p 4 -f 2.43561G --rx-gain=54 -r 25
>>
>> 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 

Re: [Discuss-gnuradio] Fwd: Re: Transmission error

[Rama V]

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  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 
> 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.43561G --tx-gain=28 -r 25
>> Receiver: ./benchmark_rx.py -p 4 -f 2.43561G --rx-gain=53 -r 25
>>
>> 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 > > 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.43561G --tx-gain=28 -r
>>> 25
>>> Receiver: ./benchmark_rx.py -p 4 -f 2.43561G --rx-gain=54 -r 25
>>>
>>> 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 =  

Re: [Discuss-gnuradio] Fwd: Re: Transmission error

[Rama V]

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.43561G --tx-gain=28 -r 25
Receiver: ./benchmark_rx.py -p 4 -f 2.43561G --rx-gain=53 -r 25

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 
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.43561G --tx-gain=28 -r 25
> Receiver: ./benchmark_rx.py -p 4 -f 2.43561G --rx-gain=54 -r 25
>
> 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 
> 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
>> 

Re: [Discuss-gnuradio] Fwd: Re: Transmission error

[Marcus Müller]

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.43561G --tx-gain=28 -r 25
> Receiver: ./benchmark_rx.py -p 4 -f 2.43561G --rx-gain=53 -r 25
>
> 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
> > 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.43561G --tx-gain=28
>> -r 25
>> Receiver: ./benchmark_rx.py -p 4 -f 2.43561G --rx-gain=54 -r
>> 25
>>
>> 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
>> > wrote:
>>
>> Ok,
>>> This is because I have changed my folder to /digital/ofdm, I
>>>   

Re: [Discuss-gnuradio] Fwd: Re: Transmission error

[Marcus Müller]

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.43561G --tx-gain=28 -r 25
> Receiver: ./benchmark_rx.py -p 4 -f 2.43561G --rx-gain=54 -r 25
>
> 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
> > 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
>> 

Re: [Discuss-gnuradio] Fwd: Re: Transmission error

[Rama V]

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.43561G --tx-gain=28 -r 25
Receiver: ./benchmark_rx.py -p 4 -f 2.43561G --rx-gain=54 -r 25

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

Re: [Discuss-gnuradio] Fwd: Re: Transmission error

[Marcus Müller]

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

Re: [Discuss-gnuradio] Fwd: Re: Transmission error

[Rama V]

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  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 
> 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> 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> wrote:
>>>
 Hi 

Re: [Discuss-gnuradio] Fwd: Re: Transmission error

[Rama V]

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"  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> 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 25
>>
>> 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
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Fwd: Re: Transmission error

[Marcus Müller]

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"  > 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
> > 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 25
>>
>> 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
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Fwd: Re: Transmission error

[Rama V]

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  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 25
>
> 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
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Fwd: Re: Transmission error

[Michael Dickens]

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 25


> 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
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Fwd: Re: Transmission error

[Michael Dickens]

Hi Rama/Dave - The benchmark examples run as standalone applications.
They do require Python, but they do not use GRC or any other GUI
interface.

Question: Are you running the OFDM or Digital/Narrowband benchmark? What
exact commands are you using for both Rx and Tx? What SDR hardware are
you using? You might have covered these items already in prior emails,
but since this was a new query it's always good to be precise -- of
course also trying to keep your query concise.

Please reply to this whole list, not just to me. In this manner, others
can join in if they so choose.

Given the lack of response to your original and even follow-up query, I
have some advice to pass on:

(1) play around with these GNU Radio-based applications; see what
they can do on your system; start with low sample rates & work
your way up.

(2) Do not expect instantaneous replies to your queries; those of us
providing any form of support juggle many things & we will get back
to you sooner or later. 24 hours is a reasonable timeframe to expect
a reply, not 1 hour or even 5 hours.

(3) Do your homework as to the questions you ask. The more informed and
precise your questions, the better we can answer them.

I hope the above helps. - MLD

On Wed, Sep 16, 2015, at 06:17 PM, Rama V wrote:
> Do I need to use gnuradio - companion for transmission and reception
> of the data packets or the benchmark_tx.py commands from the
> terminal would be enough for that to happen. I am unable to sort
> out. Kindly help.


> Regards,
>
Dave


> On Sep 16, 2015 2:59 PM, "Rama V"  wrote:
>> -- Forwarded message -- From: "Rama V"
>>  Date: Sep 15, 2015 7:47 PM Subject: Re:
>> Transmission error To:  
>> Cc:
>>
>> Please kindly help with the above error


>> Thanks,
>>
Dave


>> On Sep 14, 2015 5:02 PM, "Rama V"  wrote:
>>> I have a small doubt regarding the reception of data packets. I am
>>> attaching a small figure of the command 'uhd_fft' where I mentioned
>>> the frequency and the sampling rate as 250k. The command I have
>>> given for this  was
>>>
>>> ./benchmark_tx.py -m qpsk -M 2 --discontinuous -f 2.435G
>>>
>>> I tried to run this and I see an 'U' in the middle of transmission.
>>> Is this why I was not able to receive the packets because I get
>>>
>>> ok = False  pktno = 53034  n_rcvd =1  n_right =0
>>>
>>> My PC is Dell Inspiron 15R 5537 and I think it's somewhat a new
>>> version. Do I need to mention any sample rate in the command of
>>> benchmark. And also when I set the sample rate to 250k in my
>>> benchmark command, my laptop freezes and I need to restart it again.
>>> Do I need to give a low value? Please help and excuse for my
>>> brevity.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Fwd: Re: Transmission error

[Rama V]

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 25

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

Regards,
Dave
On Sep 17, 2015 9:09 AM, "Michael Dickens" 
wrote:

> Hi Rama/Dave - The benchmark examples run as standalone applications. They
> do require Python, but they do not use GRC or any other GUI interface.
>
> Question: Are you running the OFDM or Digital/Narrowband benchmark? What
> exact commands are you using for both Rx and Tx? What SDR hardware are you
> using? You might have covered these items already in prior emails, but
> since this was a new query it's always good to be precise -- of course also
> trying to keep your query concise.
>
> Please reply to this whole list, not just to me. In this manner, others
> can join in if they so choose.
>
> Given the lack of response to your original and even follow-up query, I
> have some advice to pass on:
>
> (1) play around with these GNU Radio-based applications; see what they can
> do on your system; start with low sample rates & work your way up.
>
> (2) Do not expect instantaneous replies to your queries; those of us
> providing any form of support juggle many things & we will get back to you
> sooner or later. 24 hours is a reasonable timeframe to expect a reply, not
> 1 hour or even 5 hours.
>
> (3) Do your homework as to the questions you ask. The more informed and
> precise your questions, the better we can answer them.
>
> I hope the above helps. - MLD
>
> On Wed, Sep 16, 2015, at 06:17 PM, Rama V wrote:
>
> Do I need to use gnuradio - companion for transmission and reception of
> the data packets or the benchmark_tx.py commands from the terminal would be
> enough for that to happen. I am unable to sort out. Kindly help.
>
> Regards,
> Dave
> On Sep 16, 2015 2:59 PM, "Rama V"  wrote:
>
> -- Forwarded message --
> From: "Rama V" 
> Date: Sep 15, 2015 7:47 PM
> Subject: Re: Transmission error
> To: 
> Cc:
>
>
> Please kindly help with the above error
>
> Thanks,
> Dave
> On Sep 14, 2015 5:02 PM, "Rama V"  wrote:
>
> I have a small doubt regarding the reception of data packets. I am
> attaching a small figure of the command 'uhd_fft' where I mentioned the
> frequency and the sampling rate as 250k. The command I have given for this
> was
>
> ./benchmark_tx.py -m qpsk -M 2 --discontinuous -f 2.435G
>
> I tried to run this and I see an 'U' in the middle of transmission. Is
> this why I was not able to receive the packets because I get
>
> ok = False pktno = 53034 n_rcvd = 1 n_right = 0
>
> My PC is Dell Inspiron 15R 5537 and I think it's somewhat a new version.
> Do I need to mention any sample rate in the command of benchmark. And also
> when I set the sample rate to 250k in my benchmark command, my laptop
> freezes and I need to restart it again. Do I need to give a low value?
> Please help and excuse for my brevity.
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Fwd: Re: Transmission error

[Rama V]

Do I need to use gnuradio - companion for transmission and reception of the
data packets or the benchmark_tx.py commands from the terminal would be
enough for that to happen. I am unable to sort out. Kindly help.

Regards,
Dave
On Sep 16, 2015 2:59 PM, "Rama V"  wrote:

> -- Forwarded message --
> From: "Rama V" 
> Date: Sep 15, 2015 7:47 PM
> Subject: Re: Transmission error
> To: 
> Cc:
>
> Please kindly help with the above error
>
> Thanks,
> Dave
> On Sep 14, 2015 5:02 PM, "Rama V"  wrote:
>
>> Hey all,
>> I have a small doubt regarding the reception of data packets. I am
>> attaching a small figure of the command 'uhd_fft' where I mentioned the
>> frequency and the sampling rate as 250k. The command I have given for this
>> was
>>
>> ./benchmark_tx.py -m qpsk -M 2 --discontinuous -f 2.435G
>>
>> I tried to run this and I see an 'U' in the middle of transmission. Is
>> this why I was not able to receive the packets because I get
>>
>> ok = False pktno = 53034 n_rcvd = 1 n_right = 0
>>
>> My PC is Dell Inspiron 15R 5537 and I think it's somewhat a new version.
>> Do I need to mention any sample rate in the command of benchmark. And also
>> when I set the sample rate to 250k in my benchmark command, my laptop
>> freezes and I need to restart it again. Do I need to give a low value?
>> Please help and excuse for my brevity.
>>
>> Thanks,
>> Dave
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio