Re: [Discuss-gnuradio] Import Error

2015-12-05 Thread Rama V
Hi,
I am trying to implement a specific application wherein the code senses for
the free channel/frequency band where the usrp can send the data and again
sense for a free channel to send the data and so on. If the channel is in
use, then it should skip the particular channel and then again sense for a
free band. I am writing my own code for this and is not any other code
installed from the Gnu-radio. When I try to run the code, it says

Import error: cannot import name usrp

I have set the Python environment to
/usr/local/lib/python2.7/dist-packages. But I do not know how exactly I can
solve for the error. Please kindly suggest. I would appreciate that. I am
attaching the code for your purposes.
Thank you.

Regards,
Dave

On Sun, Nov 29, 2015 at 3:30 PM, Rama V  wrote:

> Hey Marcus,
> Thanks for the reply. But the above program is for a specific application.
> It can be used for detecting which frequency band is available and then
> sending data in that particular channel/frequency band. I have tried using
> the application that has come with GNU Radio "usrp_spectrum_sense.py" which
> senses for free center frequency bands available. The
> "usrp_spectrum_sense_tx.py" does the above mentioned operation. So the
> python file I try to run does not work with the installed GNU Radio? If so,
> what can I do? Please suggest. For your convenience, I am attaching the
> spectrum sensing python file. I am sorry if I am not being so explicable.
>
> Thank you
>
> Regards,
> Dave
>
> On Thu, Nov 26, 2015 at 2:26 AM, Marcus Müller 
> wrote:
>
>> Hi Dave,
>>
>> like the last times with benchmark_tx, this script is something you
>> copied from somewhere else and doesn't work with the version you have
>> installed.
>> Why do you keep doing this?
>> Use the scripts that work with your *current* version of GNU Radio. This
>> one, like benchmark_tx, is contained in your GNU Radio installation itself,
>> and probably got installed to /usr/[local/]share/gnuradio/examples/uhd.
>>
>> Best regards,
>> Marcus
>>
>>
>> On 26.11.2015 01:42, Rama V wrote:
>>
>> Hi,
>> I am trying to compile a file namely usrp_spectrum_sense_tx.py but it
>> says the following error message:
>>
>> Traceback (most recent call last):
>>   File "./usrp_spectrum_sense_tx.py", line 180, in 
>> from gnuradio import gr, gru, eng_notation, optfir, window
>> ImportError: cannot import name optfir
>>
>> It is showing an ImportError. I need to sense the channel and send the
>> data on the available channel. I have set my PYTHONPATH to dist-packages.
>> Is there any specific mistake I am unable to see? Please suggest. Any help
>> is appreciated.
>>
>> Thank you,
>>
>> Regards,
>> Dave
>>
>>
>> ___
>> Discuss-gnuradio mailing 
>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
#!/usr/bin/env python
#
# Copyright 2005,2007,2008,2009 Free Software Foundation, Inc.
# 
# This file is part of GNU Radio
# 
# GNU Radio is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3, or (at your option)
# any later version.
# 
# GNU Radio is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
# 
# You should have received a copy of the GNU General Public License
# along with GNU Radio; see the file COPYING.  If not, write to
# the Free Software Foundation, Inc., 51 Franklin Street,
# Boston, MA 02110-1301, USA.
# 



"""
Note:
I consider usrp_spectrum_sense.py as the best given working example in the gnuradio project. I think also that the understanding of this program is very important to every gnuradio user (because it includes a practical FFT implementation + FSM control in its cpp code) 



Introduction:
-

1) This program can be used as a basic code for implementing wideband spectrum analyzer.
2) As we know, the USRP cannot examine more than 8 MHz of RF spectrum due to USB bus limitations.
3) So, to scan across a wide RF spectrum band (bigger than 8 MHz) we have to tune USRP RF front end in suitable steps so that we can examine a lot of spectrum, although not all at the same instant. 
4) The usrp_spectrum_sense sho

Re: [Discuss-gnuradio] Import Error

2015-11-29 Thread Rama V
Hey Marcus,
Thanks for the reply. But the above program is for a specific application.
It can be used for detecting which frequency band is available and then
sending data in that particular channel/frequency band. I have tried using
the application that has come with GNU Radio "usrp_spectrum_sense.py" which
senses for free center frequency bands available. The
"usrp_spectrum_sense_tx.py" does the above mentioned operation. So the
python file I try to run does not work with the installed GNU Radio? If so,
what can I do? Please suggest. For your convenience, I am attaching the
spectrum sensing python file. I am sorry if I am not being so explicable.

Thank you

Regards,
Dave

On Thu, Nov 26, 2015 at 2:26 AM, Marcus Müller 
wrote:

> Hi Dave,
>
> like the last times with benchmark_tx, this script is something you copied
> from somewhere else and doesn't work with the version you have installed.
> Why do you keep doing this?
> Use the scripts that work with your *current* version of GNU Radio. This
> one, like benchmark_tx, is contained in your GNU Radio installation itself,
> and probably got installed to /usr/[local/]share/gnuradio/examples/uhd.
>
> Best regards,
> Marcus
>
>
> On 26.11.2015 01:42, Rama V wrote:
>
> Hi,
> I am trying to compile a file namely usrp_spectrum_sense_tx.py but it says
> the following error message:
>
> Traceback (most recent call last):
>   File "./usrp_spectrum_sense_tx.py", line 180, in 
> from gnuradio import gr, gru, eng_notation, optfir, window
> ImportError: cannot import name optfir
>
> It is showing an ImportError. I need to sense the channel and send the
> data on the available channel. I have set my PYTHONPATH to dist-packages.
> Is there any specific mistake I am unable to see? Please suggest. Any help
> is appreciated.
>
> Thank you,
>
> Regards,
> Dave
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
#!/usr/bin/env python
#
# Copyright 2005,2007,2008,2009 Free Software Foundation, Inc.
# 
# This file is part of GNU Radio
# 
# GNU Radio is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3, or (at your option)
# any later version.
# 
# GNU Radio is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
# 
# You should have received a copy of the GNU General Public License
# along with GNU Radio; see the file COPYING.  If not, write to
# the Free Software Foundation, Inc., 51 Franklin Street,
# Boston, MA 02110-1301, USA.
# 



"""
Note:
I consider usrp_spectrum_sense.py as the best given working example in the gnuradio project. I think also that the understanding of this program is very important to every gnuradio user (because it includes a practical FFT implementation + FSM control in its cpp code) 



Introduction:
-

1) This program can be used as a basic code for implementing wideband spectrum analyzer.
2) As we know, the USRP cannot examine more than 8 MHz of RF spectrum due to USB bus limitations.
3) So, to scan across a wide RF spectrum band (bigger than 8 MHz) we have to tune USRP RF front end in suitable steps so that we can examine a lot of spectrum, although not all at the same instant. 
4) The usrp_spectrum_sense shows the way how it can be done.It steps across the spectrum and make the RF measurements. This application can
sense a large bandwidth, but not in real time, and it can do the frequency sweep over the required frequency range, 



Theory:
---

1) To use N points complex FFT X(W) analysis, we have to get N time samples x(t) which are sampled at Fs.
2) These N time samples must be time windowed using a known window function to reduce spectral leakage.
3) Performing N points complex FFT analysis.
4) The output of the complex FFT will represent the frequency spectrum contents as follows:

a) The first value of the FFT output (bin 0 == X[0]) is the passband center frequency.
b) The first half of the FFT (X[1] to X[N/2-1] contains the positive baseband frequencies,which corresponds to the passband spectrum from the center frequency out to the maximum passband frequency (from center frequency to +Fs/2).
c) The second half of the FFT (X[N/2] to X[N-1]) contains the negative baseband frequencies,which correspond to the lowest passband frequency up to the passband center

[Discuss-gnuradio] Import Error

2015-11-25 Thread Rama V
Hi,
I am trying to compile a file namely usrp_spectrum_sense_tx.py but it says
the following error message:

Traceback (most recent call last):
  File "./usrp_spectrum_sense_tx.py", line 180, in 
from gnuradio import gr, gru, eng_notation, optfir, window
ImportError: cannot import name optfir

It is showing an ImportError. I need to sense the channel and send the data
on the available channel. I have set my PYTHONPATH to dist-packages. Is
there any specific mistake I am unable to see? Please suggest. Any help is
appreciated.

Thank you,

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


Re: [Discuss-gnuradio] USRP Competition

2015-11-17 Thread Rama V
Thanks for the reply Marcus. So this channel concept lies in GNU Radio. How
can I really set from what channel I need to send the data or which
channels are free for the transmission. Do I need to write any code for
that? I am performing DARPA Spectrum competition wherein I need to perform
data transmission between two USRP by sensing which channels are free and
sending the data. Please suggest
Thank you

Regards,
Dave
On Nov 17, 2015 5:29 AM, "Marcus Müller"  wrote:

> Dave,
>
> the USRP has no notion of "channels". It's a concept that you have in your
> software that deals with the samples coming from the USRP.
> You can configure the USRP to arbitrary center frequencies.
>
> Best regards,
> Marcus
>
> On 16.11.2015 03:06, Rama V wrote:
>
> I would like to send data through specific channels among the USRP. How do
> I know what channels are available? I have tried to search for channels but
> I was not successful.  Are there any commands that I need to provide for
> the available channels? Kindly help.
> Thank you
>
> Regards,
> Dave
> On Nov 11, 2015 5:29 PM, "Rama V"  wrote:
>
>> Hey all,
>> I would like to perform a specific application of competitive
>> strategy(competition) with my two USRP available by detecting which channel
>> is available for doing that. I have used the command of
>> ./usrp_spectrum_sense.py 2.434G 2.438G which have  shown me the results
>> which is attached in the picture below. I would like to know of how to
>> select which channel or frequency band is available for performing my
>> competition and how will I be able to perform? Any suggestions are kindly
>> appreciated. Sorry if I am not too brief with that. Thanks
>>
>> Regards,
>> Dave
>>
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> 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] USRP Competition

2015-11-16 Thread Rama V
I would like to send data through specific channels among the USRP. How do
I know what channels are available? I have tried to search for channels but
I was not successful.  Are there any commands that I need to provide for
the available channels? Kindly help.
Thank you

Regards,
Dave
On Nov 11, 2015 5:29 PM, "Rama V"  wrote:

> Hey all,
> I would like to perform a specific application of competitive
> strategy(competition) with my two USRP available by detecting which channel
> is available for doing that. I have used the command of
> ./usrp_spectrum_sense.py 2.434G 2.438G which have  shown me the results
> which is attached in the picture below. I would like to know of how to
> select which channel or frequency band is available for performing my
> competition and how will I be able to perform? Any suggestions are kindly
> appreciated. Sorry if I am not too brief with that. Thanks
>
> Regards,
> Dave
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


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

2015-10-04 Thread 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 w

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

2015-10-04 Thread 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
>>

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

2015-10-01 Thread 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  pktn

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

2015-09-24 Thread 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 

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

2015-09-21 Thread 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:
&g

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

2015-09-21 Thread 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

2015-09-18 Thread 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

2015-09-17 Thread 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

2015-09-16 Thread 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


Re: [Discuss-gnuradio] Transmission error

2015-09-15 Thread Rama V
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


Re: [Discuss-gnuradio] Fwd: GNU Radio Installation Error

2015-09-10 Thread Rama V
Thanks for the help guys. The error has been solved. As Michael advised, I
have done the same thing by going into the build directory and using "rm
-rf"  command to delete the build directory and reinstalled everything from
the scratch. It worked. I guess I can approach later if I encounter any
other problems in my experiment. Thank you.

Regards,
Dave

On Thu, Sep 10, 2015 at 3:21 PM, Rama V  wrote:

> Hi,
> Thanks for the reply. Sorry to trouble you. If I perform the "rm -rf"
> command, I guess the entire contents in the build directory gets deleted
> right? So how exactly should I give the command. Like gnuradio/build $ sudo
> rm -rf? Kindly help as I am performing this command newly.
>
> Thanks,
> Dave
>
> On Thu, Sep 10, 2015 at 2:07 AM, Marcus Müller 
> wrote:
>
>> Dave,
>>
>> please refrain from asking for help on mails just because you did not
>> receive answer within 5 hours.
>>
>> Best regards,
>> Marcus
>>
>>
>> On 10.09.2015 03:34, Rama V wrote:
>>
>> Anyone. Kindly help with the above error.
>>
>> Regards,
>> Dave
>> On Sep 9, 2015 4:46 PM, "Rama V" < ramav...@gmail.com>
>> wrote:
>>
>>> Hello,
>>> I have uninstalled GNU Radio from /gnuradio/build directory because of
>>> an error and I wish to reinstall it. But when I try to do that from the
>>> same directory by using 'sudo make install', I keep getting an error as
>>>
>>> [ 97%] Built target pygen_gr_fcd_swig_ecb11
>>> [ 98%] Built target pygen_gr_fcd_python_fcd_37821
>>> Linking CXX executable fcd_nfm_rx
>>> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
>>> `libusb_free_config_descriptor'
>>> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
>>> `libusb_get_config_descriptor'
>>> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
>>> `libusb_open'
>>> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
>>> `libusb_detach_kernel_driver'
>>> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
>>> `libusb_get_device_list'
>>> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
>>> `libusb_control_transfer'
>>> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
>>> `libusb_exit'
>>> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
>>> `libusb_free_device_list'
>>> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
>>> `libusb_cancel_transfer'
>>> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
>>> `libusb_free_transfer'
>>> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
>>> `libusb_submit_transfer'
>>> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
>>> `libusb_interrupt_transfer'
>>> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
>>> `libusb_get_device_descriptor'
>>> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
>>> `libusb_claim_interface'
>>> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
>>> `libusb_handle_events'
>>> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
>>> `libusb_handle_events_completed'
>>> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
>>> `libusb_close'
>>> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
>>> `libusb_kernel_driver_active'
>>> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
>>> `libusb_release_interface'
>>> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
>>> `libusb_get_bus_number'
>>> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
>>> `libusb_init'
>>> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
>>> `libusb_get_device_address'
>>> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
>>> `libusb_alloc_transfer'
>>> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
>>> `libusb_get_active_config_descriptor'
>>> collect2: error: ld returned 1 exit status
>>> make[2]: *** [gr-fcd/examples/c++/fcd_nfm_rx] Error 1
>>> make[1]: *** [gr-fcd/examples/c++/CMakeFiles/fcd_nfm_rx.dir/all] Error 2
>>> make: *** [all] Error 2
>>>
>>>  Please help as to what I can do. I am in the middle of my experiment.
>>> Any suggestions will be kindly helpful.
>>>
>>> Thanks,
>>> Dave
>>>
>>>
>>
>> ___
>> Discuss-gnuradio mailing 
>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>>
>> ___
>> 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: GNU Radio Installation Error

2015-09-10 Thread Rama V
Hi,
Thanks for the reply. Sorry to trouble you. If I perform the "rm -rf"
command, I guess the entire contents in the build directory gets deleted
right? So how exactly should I give the command. Like gnuradio/build $ sudo
rm -rf? Kindly help as I am performing this command newly.

Thanks,
Dave

On Thu, Sep 10, 2015 at 2:07 AM, Marcus Müller 
wrote:

> Dave,
>
> please refrain from asking for help on mails just because you did not
> receive answer within 5 hours.
>
> Best regards,
> Marcus
>
>
> On 10.09.2015 03:34, Rama V wrote:
>
> Anyone. Kindly help with the above error.
>
> Regards,
> Dave
> On Sep 9, 2015 4:46 PM, "Rama V" < ramav...@gmail.com>
> wrote:
>
>> Hello,
>> I have uninstalled GNU Radio from /gnuradio/build directory because of an
>> error and I wish to reinstall it. But when I try to do that from the same
>> directory by using 'sudo make install', I keep getting an error as
>>
>> [ 97%] Built target pygen_gr_fcd_swig_ecb11
>> [ 98%] Built target pygen_gr_fcd_python_fcd_37821
>> Linking CXX executable fcd_nfm_rx
>> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
>> `libusb_free_config_descriptor'
>> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
>> `libusb_get_config_descriptor'
>> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
>> `libusb_open'
>> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
>> `libusb_detach_kernel_driver'
>> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
>> `libusb_get_device_list'
>> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
>> `libusb_control_transfer'
>> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
>> `libusb_exit'
>> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
>> `libusb_free_device_list'
>> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
>> `libusb_cancel_transfer'
>> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
>> `libusb_free_transfer'
>> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
>> `libusb_submit_transfer'
>> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
>> `libusb_interrupt_transfer'
>> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
>> `libusb_get_device_descriptor'
>> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
>> `libusb_claim_interface'
>> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
>> `libusb_handle_events'
>> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
>> `libusb_handle_events_completed'
>> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
>> `libusb_close'
>> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
>> `libusb_kernel_driver_active'
>> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
>> `libusb_release_interface'
>> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
>> `libusb_get_bus_number'
>> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
>> `libusb_init'
>> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
>> `libusb_get_device_address'
>> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
>> `libusb_alloc_transfer'
>> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
>> `libusb_get_active_config_descriptor'
>> collect2: error: ld returned 1 exit status
>> make[2]: *** [gr-fcd/examples/c++/fcd_nfm_rx] Error 1
>> make[1]: *** [gr-fcd/examples/c++/CMakeFiles/fcd_nfm_rx.dir/all] Error 2
>> make: *** [all] Error 2
>>
>>  Please help as to what I can do. I am in the middle of my experiment.
>> Any suggestions will be kindly helpful.
>>
>> Thanks,
>> Dave
>>
>>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> 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: GNU Radio Installation Error

2015-09-09 Thread Rama V
Anyone. Kindly help with the above error.

Regards,
Dave
On Sep 9, 2015 4:46 PM, "Rama V"  wrote:

> Hello,
> I have uninstalled GNU Radio from /gnuradio/build directory because of an
> error and I wish to reinstall it. But when I try to do that from the same
> directory by using 'sudo make install', I keep getting an error as
>
> [ 97%] Built target pygen_gr_fcd_swig_ecb11
> [ 98%] Built target pygen_gr_fcd_python_fcd_37821
> Linking CXX executable fcd_nfm_rx
> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
> `libusb_free_config_descriptor'
> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
> `libusb_get_config_descriptor'
> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
> `libusb_open'
> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
> `libusb_detach_kernel_driver'
> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
> `libusb_get_device_list'
> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
> `libusb_control_transfer'
> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
> `libusb_exit'
> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
> `libusb_free_device_list'
> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
> `libusb_cancel_transfer'
> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
> `libusb_free_transfer'
> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
> `libusb_submit_transfer'
> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
> `libusb_interrupt_transfer'
> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
> `libusb_get_device_descriptor'
> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
> `libusb_claim_interface'
> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
> `libusb_handle_events'
> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
> `libusb_handle_events_completed'
> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
> `libusb_close'
> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
> `libusb_kernel_driver_active'
> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
> `libusb_release_interface'
> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
> `libusb_get_bus_number'
> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
> `libusb_init'
> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
> `libusb_get_device_address'
> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
> `libusb_alloc_transfer'
> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
> `libusb_get_active_config_descriptor'
> collect2: error: ld returned 1 exit status
> make[2]: *** [gr-fcd/examples/c++/fcd_nfm_rx] Error 1
> make[1]: *** [gr-fcd/examples/c++/CMakeFiles/fcd_nfm_rx.dir/all] Error 2
> make: *** [all] Error 2
>
>  Please help as to what I can do. I am in the middle of my experiment. Any
> suggestions will be kindly helpful.
>
> Thanks,
> Dave
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


[Discuss-gnuradio] GNU Radio Installation Error

2015-09-09 Thread Rama V
Hello all,
I have uninstalled GNU Radio from /gnuradio/build directory because of an
error and I wish to reinstall it. But when I try to do that from the same
directory by using 'sudo make install', I keep getting an error as

[ 97%] Built target pygen_gr_fcd_swig_ecb11
[ 98%] Built target pygen_gr_fcd_python_fcd_37821
Linking CXX executable fcd_nfm_rx
../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
`libusb_free_config_descriptor'
../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
`libusb_get_config_descriptor'
../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
`libusb_open'
../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
`libusb_detach_kernel_driver'
../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
`libusb_get_device_list'
../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
`libusb_control_transfer'
../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
`libusb_exit'
../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
`libusb_free_device_list'
../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
`libusb_cancel_transfer'
../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
`libusb_free_transfer'
../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
`libusb_submit_transfer'
../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
`libusb_interrupt_transfer'
../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
`libusb_get_device_descriptor'
../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
`libusb_claim_interface'
../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
`libusb_handle_events'
../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
`libusb_handle_events_completed'
../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
`libusb_close'
../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
`libusb_kernel_driver_active'
../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
`libusb_release_interface'
../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
`libusb_get_bus_number'
../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
`libusb_init'
../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
`libusb_get_device_address'
../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
`libusb_alloc_transfer'
../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
`libusb_get_active_config_descriptor'
collect2: error: ld returned 1 exit status
make[2]: *** [gr-fcd/examples/c++/fcd_nfm_rx] Error 1
make[1]: *** [gr-fcd/examples/c++/CMakeFiles/fcd_nfm_rx.dir/all] Error 2
make: *** [all] Error 2

 Please help as to what I can do. I am in the middle of my experiment. Any
suggestions will be kindly helpful.

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


Re: [Discuss-gnuradio] A small error in benchmark_tx file

2015-09-08 Thread Rama V
Thanks for the reply. It's /gnuradio/build directory from which I need to
uninstall.

Thanks,
Dave
On Sep 8, 2015 4:03 PM, "Marcus Müller"  wrote:

> You need to do it from the same, unmodified directory where you did "make
> install" last. If you deleted that, the information which files have to be
> uninstalled are lost. You can only hope for the best and install over
> without deinstallation first.
>
> Best regards,
> Marcus
>
> On 08.09.2015 23:02, Rama V wrote:
>
> I am sorry for asking so many times. I have tried make uninstall but shows
> this
>
> make: *** No rule to make target 'uninstall'. Stop.
>
> Please advise what I can do. I am performing it newly.
>
> Thanks,
> Dave
> On Sep 8, 2015 3:13 PM, "Marcus Müller"  wrote:
>
>> then
>>
>> make uninstall
>>
>> will be the right thing to uninstall GNU Radio.
>>
>> Best regards,
>> Marcus
>>
>> On 08.09.2015 21:56, Rama V wrote:
>>
>> I built UHD manually by using the command 'cmake' and make install in
>> the  UHD build directory. Do you kindly need any other information on that
>> which I could provide with? It could be of help.
>>
>> Thanks,
>> Dave
>> On Sep 8, 2015 2:48 PM, "Marcus Müller"  wrote:
>>
>>> Hi Dave,
>>>
>>> I don't know how you installed, what OS / distro you are using etc.
>>> This is your computer, I can't really tell or teach you how to
>>> administrate it.
>>>
>>> Best regards,
>>> Marcus
>>>
>>> On 08.09.2015 20:14, Rama V wrote:
>>>
>>> Hey Marcus,
>>> For reinstalling,  I guess I need to first do an uninstall for GNU RADIO
>>> right?  Do I need to type in sudo- remove? Please help.
>>>
>>> Thanks,
>>> Dave
>>> On Sep 8, 2015 11:13 AM, "Rama V"  wrote:
>>>
>>>> I guess I would like to be preferred as Dave. Regarding the problem,
>>>> I'll follow your advise and approach if any further problems are
>>>> encountered.
>>>>
>>>> Thanks,
>>>> Dave
>>>> On Sep 8, 2015 11:06 AM, "Marcus Müller" 
>>>> wrote:
>>>>
>>>>> Hi Rama, or Dave,
>>>>>
>>>>> first of all, can we stick with one name? I personally find Rama is a
>>>>> good name, but Dave is fine with me, too. However, you're having the exact
>>>>> same problem as Ravi, who is also using multiple names. This is really 
>>>>> hard
>>>>> to follow.
>>>>>
>>>>> then: I think reinstallation is the cleanest approach. I, by the way,
>>>>> don't think there's actually a bug in 3.7.7, I suspect that you, by
>>>>> accident, broke the scripts during your modifications.
>>>>>
>>>>> Best regards,
>>>>> Marcus
>>>>>
>>>>> On 08.09.2015 17:59, Rama V wrote:
>>>>>
>>>>> Hey Marcus,
>>>>> Thanks for the advise. I am sorry to reply lately. So you want me to
>>>>> reinstall the GNU Radio again to recover the original files? If so, then I
>>>>> might be able to do it because there is a new version of GNU Radio 3.7.8 
>>>>> to
>>>>> remove that error.
>>>>>
>>>>> Thanks,
>>>>> Dave
>>>>>
>>>>>
>>>>> ___
>>>>> Discuss-gnuradio mailing 
>>>>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>>
>>>>>
>>>>>
>>>>> ___
>>>>> 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] A small error in benchmark_tx file

2015-09-08 Thread Rama V
I am sorry for asking so many times. I have tried make uninstall but shows
this

make: *** No rule to make target 'uninstall'. Stop.

Please advise what I can do. I am performing it newly.

Thanks,
Dave
On Sep 8, 2015 3:13 PM, "Marcus Müller"  wrote:

> then
>
> make uninstall
>
> will be the right thing to uninstall GNU Radio.
>
> Best regards,
> Marcus
>
> On 08.09.2015 21:56, Rama V wrote:
>
> I built UHD manually by using the command 'cmake' and make install in the
> UHD build directory. Do you kindly need any other information on that which
> I could provide with? It could be of help.
>
> Thanks,
> Dave
> On Sep 8, 2015 2:48 PM, "Marcus Müller"  wrote:
>
>> Hi Dave,
>>
>> I don't know how you installed, what OS / distro you are using etc.
>> This is your computer, I can't really tell or teach you how to
>> administrate it.
>>
>> Best regards,
>> Marcus
>>
>> On 08.09.2015 20:14, Rama V wrote:
>>
>> Hey Marcus,
>> For reinstalling,  I guess I need to first do an uninstall for GNU RADIO
>> right?  Do I need to type in sudo- remove? Please help.
>>
>> Thanks,
>> Dave
>> On Sep 8, 2015 11:13 AM, "Rama V"  wrote:
>>
>>> I guess I would like to be preferred as Dave. Regarding the problem,
>>> I'll follow your advise and approach if any further problems are
>>> encountered.
>>>
>>> Thanks,
>>> Dave
>>> On Sep 8, 2015 11:06 AM, "Marcus Müller" 
>>> wrote:
>>>
>>>> Hi Rama, or Dave,
>>>>
>>>> first of all, can we stick with one name? I personally find Rama is a
>>>> good name, but Dave is fine with me, too. However, you're having the exact
>>>> same problem as Ravi, who is also using multiple names. This is really hard
>>>> to follow.
>>>>
>>>> then: I think reinstallation is the cleanest approach. I, by the way,
>>>> don't think there's actually a bug in 3.7.7, I suspect that you, by
>>>> accident, broke the scripts during your modifications.
>>>>
>>>> Best regards,
>>>> Marcus
>>>>
>>>> On 08.09.2015 17:59, Rama V wrote:
>>>>
>>>> Hey Marcus,
>>>> Thanks for the advise. I am sorry to reply lately. So you want me to
>>>> reinstall the GNU Radio again to recover the original files? If so, then I
>>>> might be able to do it because there is a new version of GNU Radio 3.7.8 to
>>>> remove that error.
>>>>
>>>> Thanks,
>>>> Dave
>>>>
>>>>
>>>> ___
>>>> Discuss-gnuradio mailing 
>>>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>
>>>>
>>>>
>>>> ___
>>>> 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] A small error in benchmark_tx file

2015-09-08 Thread Rama V
Hey Marcus,
For reinstalling,  I guess I need to first do an uninstall for GNU RADIO
right?  Do I need to type in sudo- remove? Please help.

Thanks,
Dave
On Sep 8, 2015 11:13 AM, "Rama V"  wrote:

> I guess I would like to be preferred as Dave. Regarding the problem, I'll
> follow your advise and approach if any further problems are encountered.
>
> Thanks,
> Dave
> On Sep 8, 2015 11:06 AM, "Marcus Müller"  wrote:
>
>> Hi Rama, or Dave,
>>
>> first of all, can we stick with one name? I personally find Rama is a
>> good name, but Dave is fine with me, too. However, you're having the exact
>> same problem as Ravi, who is also using multiple names. This is really hard
>> to follow.
>>
>> then: I think reinstallation is the cleanest approach. I, by the way,
>> don't think there's actually a bug in 3.7.7, I suspect that you, by
>> accident, broke the scripts during your modifications.
>>
>> Best regards,
>> Marcus
>>
>> On 08.09.2015 17:59, Rama V wrote:
>>
>> Hey Marcus,
>> Thanks for the advise. I am sorry to reply lately. So you want me to
>> reinstall the GNU Radio again to recover the original files? If so, then I
>> might be able to do it because there is a new version of GNU Radio 3.7.8 to
>> remove that error.
>>
>> Thanks,
>> Dave
>>
>>
>> ___
>> Discuss-gnuradio mailing 
>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>>
>> ___
>> 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] A small error in benchmark_tx file

2015-09-08 Thread Rama V
I built UHD manually by using the command 'cmake' and make install in the
UHD build directory. Do you kindly need any other information on that which
I could provide with? It could be of help.

Thanks,
Dave
On Sep 8, 2015 2:48 PM, "Marcus Müller"  wrote:

> Hi Dave,
>
> I don't know how you installed, what OS / distro you are using etc.
> This is your computer, I can't really tell or teach you how to
> administrate it.
>
> Best regards,
> Marcus
>
> On 08.09.2015 20:14, Rama V wrote:
>
> Hey Marcus,
> For reinstalling,  I guess I need to first do an uninstall for GNU RADIO
> right?  Do I need to type in sudo- remove? Please help.
>
> Thanks,
> Dave
> On Sep 8, 2015 11:13 AM, "Rama V"  wrote:
>
>> I guess I would like to be preferred as Dave. Regarding the problem, I'll
>> follow your advise and approach if any further problems are encountered.
>>
>> Thanks,
>> Dave
>> On Sep 8, 2015 11:06 AM, "Marcus Müller" 
>> wrote:
>>
>>> Hi Rama, or Dave,
>>>
>>> first of all, can we stick with one name? I personally find Rama is a
>>> good name, but Dave is fine with me, too. However, you're having the exact
>>> same problem as Ravi, who is also using multiple names. This is really hard
>>> to follow.
>>>
>>> then: I think reinstallation is the cleanest approach. I, by the way,
>>> don't think there's actually a bug in 3.7.7, I suspect that you, by
>>> accident, broke the scripts during your modifications.
>>>
>>> Best regards,
>>> Marcus
>>>
>>> On 08.09.2015 17:59, Rama V wrote:
>>>
>>> Hey Marcus,
>>> Thanks for the advise. I am sorry to reply lately. So you want me to
>>> reinstall the GNU Radio again to recover the original files? If so, then I
>>> might be able to do it because there is a new version of GNU Radio 3.7.8 to
>>> remove that error.
>>>
>>> Thanks,
>>> Dave
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing 
>>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>>
>>> ___
>>> 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] A small error in benchmark_tx file

2015-09-08 Thread Rama V
I guess I would like to be preferred as Dave. Regarding the problem, I'll
follow your advise and approach if any further problems are encountered.

Thanks,
Dave
On Sep 8, 2015 11:06 AM, "Marcus Müller"  wrote:

> Hi Rama, or Dave,
>
> first of all, can we stick with one name? I personally find Rama is a good
> name, but Dave is fine with me, too. However, you're having the exact same
> problem as Ravi, who is also using multiple names. This is really hard to
> follow.
>
> then: I think reinstallation is the cleanest approach. I, by the way,
> don't think there's actually a bug in 3.7.7, I suspect that you, by
> accident, broke the scripts during your modifications.
>
> Best regards,
> Marcus
>
> On 08.09.2015 17:59, Rama V wrote:
>
> Hey Marcus,
> Thanks for the advise. I am sorry to reply lately. So you want me to
> reinstall the GNU Radio again to recover the original files? If so, then I
> might be able to do it because there is a new version of GNU Radio 3.7.8 to
> remove that error.
>
> Thanks,
> Dave
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> 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


[Discuss-gnuradio] A small error in benchmark_tx file

2015-09-08 Thread Rama V
Hey Marcus,
Thanks for the advise. I am sorry to reply lately. So you want me to
reinstall the GNU Radio again to recover the original files? If so, then I
might be able to do it because there is a new version of GNU Radio 3.7.8 to
remove that error.

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