[Discuss-gnuradio] Mono-Pulse for GRC 3.6.0

2012-06-11 Thread Michael Hill
Hi,

I'm quite new to Linux / GNU Radio / these lists and am looking to generate
Signal Pulses.
It seems that gnuradio-radar-mono.py would be ideal for this but wasn't
installed with my GRC 3.6
nor has it been updated for a long time. According to the documentation it
requires a custom FPGA build to get working?

If I try to install it i suddenly can't run GNU Radio 3.6.0 but I get an
error:
grc Traceback (most recent call last): File "./grc", line 45, in <*module*>
"""%*gr*.*version*() AttributeError: '*module*' object has no attribute
'version' *...*

>From what I've read I need do an sudo make install but I found the
gnuradio-mono-py as an update that I installed via Synaptic.

I'm not quite sure where I should be directing my efforts
e.g.
Is the update of gnuradio-radar-mono.py in a easy installable cmake form
somewhere?
Is it compatible at all wit 3.6.0?
Has this functionality been surpassed by other functions in GNU Radio or
discarded?
Is it true that i'll need to a custom FPGA build?

I'm a bit confused,

Thanks in advance,

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


Re: [Discuss-gnuradio] b100 error

2012-06-11 Thread Josh Blum

> 
> the SID keeps changing although .. While I saw I similar problem earlier in
> this
> thread(http://old.nabble.com/uhd-b100-problems-td33345827.html#a33345827  )
> but I am afraid that the problem still persists :( 
> 
> my UHD version is uhd-images_003.004.001-109-g6ca39ad9

This is an RX issue. I really swear I had nailed this down a while ago.
Do you mind trying an update?

It looks like you are using the master branch.
I would update the host code and grab images here:
http://files.ettus.com/binaries/master_images/

-josh

> 
> Thanks 
> 
> -
> Sumit Kr.
> Research Assistant
> Communication Research center
> IIIT Hyderabad
> India

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


[Discuss-gnuradio] Patch to Include LNA enhancement and IF gain and filter settings for FCD

2012-06-11 Thread Bryan Biedenkapp
Hi All,

I've created a patch based on the gnuradio-3.6.1git sources to include
extra options for the FunCube Dongle on GNU Radio. I'm not sure of the
policies or procedures for posting a patch to the group for review (new to
this group). So, I have attached the patch as a file.

If this is not the proper place for this and there is a official location,
please let me know!

Thanks,

-- 
Bryan Biedenkapp
GMRS Lic. WQDK979

+15db louder than "my ears are bleeding and I'm developing an aneurism".

Eleven. Exactly. One Louder.


gr-fcd_enhancements.patch
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] b100 error

2012-06-11 Thread tzopik
2012/6/11 Josh Blum :
>
>>
>> the SID keeps changing although .. While I saw I similar problem earlier in
>> this
>> thread(http://old.nabble.com/uhd-b100-problems-td33345827.html#a33345827  )
>> but I am afraid that the problem still persists :(
>>
>> my UHD version is uhd-images_003.004.001-109-g6ca39ad9
>
> This is an RX issue. I really swear I had nailed this down a while ago.
> Do you mind trying an update?

I have experienced the same issue with B100 and UHD:
linux; GNU C++ version 4.6.3; Boost_104900; UHD_003.004.002-137-g49d4f8e4

the FPGA master images:
003.004.001-109-g6ca39ad9
Wed Apr 25 19:13:06 PDT 2012

the SID message appears in first overrun and after this the B100
device needs to power down otherwise the SID message not disappears.

I tried various combinations of versions from git repo (main, master,
next) with the respective images and the problem persist. I use Gentoo
Linux 64bit, kernel 3.4.0, glibc 2.15, gcc 4.6.3


>
> It looks like you are using the master branch.
> I would update the host code and grab images here:
> http://files.ettus.com/binaries/master_images/
>
> -josh
>
>>
>> Thanks
>>
>> -
>> Sumit Kr.
>> Research Assistant
>> Communication Research center
>> IIIT Hyderabad
>> India
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



-- 
Cumprimentos,

José Quaresma

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


[Discuss-gnuradio] /bin/bash: line 15: --destdir: command not found

2012-06-11 Thread Baidoo-Williams, Henry E
Hello all,

I am running this command; sudo make install on the UCLA Zigbee PHY and I get 
this

wlab@ubuntu:~/gr-ieee802-15-4$ sudo make install
Making install in config
make[1]: Entering directory `/home/wlab/gr-ieee802-15-4/config'
make[2]: Entering directory `/home/wlab/gr-ieee802-15-4/config'
make[2]: Nothing to be done for `install-exec-am'.
make[2]: Nothing to be done for `install-data-am'.
make[2]: Leaving directory `/home/wlab/gr-ieee802-15-4/config'
make[1]: Leaving directory `/home/wlab/gr-ieee802-15-4/config'
Making install in src
make[1]: Entering directory `/home/wlab/gr-ieee802-15-4/src'
Making install in lib
make[2]: Entering directory `/home/wlab/gr-ieee802-15-4/src/lib'
make  install-am
make[3]: Entering directory `/home/wlab/gr-ieee802-15-4/src/lib'
make[4]: Entering directory `/home/wlab/gr-ieee802-15-4/src/lib'
make[4]: Nothing to be done for `install-exec-am'.
test -z "/usr/local/include/gnuradio" || /bin/mkdir -p 
"/usr/local/include/gnuradio"
 /usr/bin/install -c -m 644 ucla_cc1k_correlator_cb.h ucla_sos_packet_sink.h 
ucla_ieee802_15_4_packet_sink.h ucla_qpsk_modulator_cc.h 
ucla_symbols_to_chips_bi.h ucla_manchester_ff.h ucla_multichanneladd_cc.h 
ucla_delay_cc.h '/usr/local/include/gnuradio'
test -z "/usr/local/lib/python2.7/dist-packages/gnuradio" || /bin/mkdir -p 
"/usr/local/lib/python2.7/dist-packages/gnuradio"
 /bin/bash ../../libtool   --mode=install /usr/bin/install -c   _ucla.la 
'/usr/local/lib/python2.7/dist-packages/gnuradio'
libtool: install: /usr/bin/install -c .libs/_ucla.so 
/usr/local/lib/python2.7/dist-packages/gnuradio/_ucla.so
libtool: install: /usr/bin/install -c .libs/_ucla.lai 
/usr/local/lib/python2.7/dist-packages/gnuradio/_ucla.la
libtool: finish: 
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/sbin" 
ldconfig -n /usr/local/lib/python2.7/dist-packages/gnuradio
--
Libraries have been installed in:
   /usr/local/lib/python2.7/dist-packages/gnuradio

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
   - add LIBDIR to the `LD_LIBRARY_PATH' environment variable
 during execution
   - add LIBDIR to the `LD_RUN_PATH' environment variable
 during linking
   - use the `-Wl,-rpath -Wl,LIBDIR' linker flag
   - have your system administrator add LIBDIR to `/etc/ld.so.conf'

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
--
test -z "/usr/local/lib/python2.7/dist-packages/gnuradio" || /bin/mkdir -p 
"/usr/local/lib/python2.7/dist-packages/gnuradio"
 /usr/bin/install -c -m 644 ucla.py 
'/usr/local/lib/python2.7/dist-packages/gnuradio'
Byte-compiling python modules...
ucla.py
Byte-compiling python modules (optimized versions) ...
ucla.py
test -z "/usr/local/include/gnuradio/swig -I/usr/local/include/gruel/swig" || 
/bin/mkdir -p "/usr/local/include/gnuradio/swig -I/usr/local/include/gruel/swig"
 /usr/bin/install -c -m 644 ucla.i '/usr/local/include/gnuradio/swig 
-I/usr/local/include/gruel/swig'
make[4]: Leaving directory `/home/wlab/gr-ieee802-15-4/src/lib'
make[3]: Leaving directory `/home/wlab/gr-ieee802-15-4/src/lib'
make[2]: Leaving directory `/home/wlab/gr-ieee802-15-4/src/lib'
Making install in python
make[2]: Entering directory `/home/wlab/gr-ieee802-15-4/src/python'
make[3]: Entering directory `/home/wlab/gr-ieee802-15-4/src/python'
make[3]: Nothing to be done for `install-exec-am'.
test -z "/usr/local/lib/python2.7/dist-packages/gnuradio/ucla_blks" || 
/bin/mkdir -p "/usr/local/lib/python2.7/dist-packages/gnuradio/ucla_blks"
 /usr/bin/install -c -m 644 __init__.py cc1k.py cc1k_sos_pkt.py ieee802_15_4.py 
ieee802_15_4_pkt.py crc16.py crc8.py 
'/usr/local/lib/python2.7/dist-packages/gnuradio/ucla_blks'
/bin/bash: line 15: --destdir: command not found
make[3]: *** [install-uclapythonPYTHON] Error 127
make[3]: Leaving directory `/home/wlab/gr-ieee802-15-4/src/python'
make[2]: *** [install-am] Error 2
make[2]: Leaving directory `/home/wlab/gr-ieee802-15-4/src/python'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory `/home/wlab/gr-ieee802-15-4/src'
make: *** [install-recursive] Error 1

I am running Ubuntu 12.04 and  GNU Radio Companion 3.6.1. Can anyone help on 
clearing the errors highlighted in red?


Respectfully,
H.E. Baidoo-Williams

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


[Discuss-gnuradio] GNU Radio Release 3.6.1 available for download

2012-06-11 Thread Johnathan Corgan
GNU Radio release 3.6.1 is now available for download:

http://gnuradio.org/releases/gnuradio/gnuradio-3.6.1

We have stopped creating a separate gr-howto-write-a-block tarball; its
contents are now distributed within the main gnuradio tarball.

This release contains numerous bug fixes, some new signal processing
blocks, a new Python API documentation system, and the first steps in the
code reorganization that will become complete in the 3.7 API release.

The detailed changelog is here:

http://gnuradio.org/redmine/projects/gnuradio/wiki/ChangeLogV3_6_1

Contributors this release:

Alexandru Csete
Ben Reynwar
Donald Porges
James Cutler
Jaroslav Skarvada
Johnathan Corgan
Jose Quaresma
Josh Blum
Marcus Leech
Moritz Fischer
Nicholas Corgan
Nick Foster
Nick McCarty
Tom Rondeau
Tim O'Shea

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


Re: [Discuss-gnuradio] Mono-Pulse for GRC 3.6.0

2012-06-11 Thread Johnathan Corgan
On Mon, Jun 11, 2012 at 1:12 AM, Michael Hill  wrote:


> I'm quite new to Linux / GNU Radio / these lists and am looking to
> generate Signal Pulses.
> It seems that gnuradio-radar-mono.py would be ideal for this but wasn't
> installed with my GRC 3.6
> nor has it been updated for a long time. According to the documentation it
> requires a custom FPGA build to get working?
>

Sorry to inform you but the functionality in gr-radar-mono was obsoleted
some time ago and removed from the GNU Radio distribution.  It required a
custom USRP1 FPGA image which is no longer distributed, and its
functionality depened on the old libusrp library that is also no longer
part of GNU Radio.

That being said, I'd encourage you define the functionality you want for
your application and implement these on your own via GRC or Python if
possible.  The process of understanding what features you want and mapping
those to the blocks available in GNU Radio is a great learning experience.

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


[Discuss-gnuradio] NEC uPD720200 and USRP B100

2012-06-11 Thread Vincenzo Pellegrini
Hi Nick and everybody,

today I tried to access my B100 via the NEC Corporation uPD720200
usb 3.0 controller that you quoted in this message:

http://www.mail-archive.com/discuss-gnuradio@gnu.org/msg35877.html

installed on a PCIe USB 3.0 expansion card.

UHD could not find devices (./uhd_find_devices)

whereas it actually can find my B100 both if it is connected to the USB 2.0
controller on-board the PC motherboard and if it's connected to a PCI
USB 2.0 expansion card.

do you have any search hints for this, is your uPD720200 on-board the
motherboard or on a separate device?

thanks and regards

vincenzo


--
Vincenzo Pellegrini
http://www.youtube.com/user/wwvince1

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


Re: [Discuss-gnuradio] GNU Radio Release 3.6.1 available for download

2012-06-11 Thread Johnathan Corgan
On Mon, Jun 11, 2012 at 9:42 AM, Johnathan Corgan <
jcor...@corganenterprises.com> wrote:

>
> Contributors this release:
>
> James Cutler
>

My apologies; this should have been Justin Cutler.

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


Re: [Discuss-gnuradio] NEC uPD720200 and USRP B100

2012-06-11 Thread Nick Foster
On Mon, Jun 11, 2012 at 10:28 AM, Vincenzo Pellegrini wrote:

> Hi Nick and everybody,
>
> today I tried to access my B100 via the NEC Corporation uPD720200
> usb 3.0 controller that you quoted in this message:
>
> http://www.mail-archive.com/discuss-gnuradio@gnu.org/msg35877.html
>
> installed on a PCIe USB 3.0 expansion card.
>
> UHD could not find devices (./uhd_find_devices)
>
> whereas it actually can find my B100 both if it is connected to the USB 2.0
> controller on-board the PC motherboard and if it's connected to a PCI
> USB 2.0 expansion card.
>

Mine's onboard, although it really shouldn't make a difference. Can you
paste the output of lsusb and lspci -v?

--n


>
> do you have any search hints for this, is your uPD720200 on-board the
> motherboard or on a separate device?
>
> thanks and regards
>
> vincenzo
>
>
> --
> Vincenzo Pellegrini
> http://www.youtube.com/user/wwvince1
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] b100 error

2012-06-11 Thread sumitstop

Hi Josh, 
Did you update the code :-)

Josh Blum-3 wrote:
> 
> 
>> 
>> the SID keeps changing although .. While I saw I similar problem earlier
>> in
>> this
>> thread(http://old.nabble.com/uhd-b100-problems-td33345827.html#a33345827 
>> )
>> but I am afraid that the problem still persists :( 
>> 
>> my UHD version is uhd-images_003.004.001-109-g6ca39ad9
> 
> This is an RX issue. I really swear I had nailed this down a while ago.
> Do you mind trying an update?
> 
> It looks like you are using the master branch.
> I would update the host code and grab images here:
> http://files.ettus.com/binaries/master_images/
> 
> -josh
> 
>> 
>> Thanks 
>> 
>> -
>> Sumit Kr.
>> Research Assistant
>> Communication Research center
>> IIIT Hyderabad
>> India
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 


-
Sumit Kr.
Research Assistant
Communication Research center
IIIT Hyderabad
India
-- 
View this message in context: 
http://old.nabble.com/b100-error-tp33991288p33995193.html
Sent from the GnuRadio mailing list archive at Nabble.com.


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


Re: [Discuss-gnuradio] Patch to Include LNA enhancement and IF gain and filter settings for FCD

2012-06-11 Thread Alexandru Csete
On Mon, Jun 11, 2012 at 6:21 PM, Bryan Biedenkapp  wrote:
> Hi All,
>
> I've created a patch based on the gnuradio-3.6.1git sources to include extra
> options for the FunCube Dongle on GNU Radio. I'm not sure of the policies or
> procedures for posting a patch to the group for review (new to this group).
> So, I have attached the patch as a file.

Hi Bryan (and others),

Thanks for your patch. I will review it as soon as I can, however,
before I do that I would like to ask you and others whether we really
want all this functionality.

The reason why these API calls weren't included in gr-fcd from the
beginning is very simple: In my 1.5 years working with the Funcube
Dongle, I have never needed to adjust anything else than the
frequency, I/Q corrections and LNA gain. I remember we have spent a
lot of effort implementing the full API in Qthid, then got very
disappointed to see that the default values were always the best ones
and most controls didn't even have any practical effect. Now I still
have to maintain these functions in qthid, check that they still work
with new firmware releases, etc. and for what use?

I can imagine the LNA enhancement to be of some use so I guess we
could include that without further discussions.

Concerning the IF filters: They are by default at their narrowest
setting, which is 1 MHz and 2.15 MHz. The bandwidth of the FCD is 96
kHz. Is there any practical reason why anyone would want to increase
the IF bandwidth?

Similar argument for the IF gain settings: They are by default set to
have lowest gain and with these settings the FCD has sufficient
sensitivity. IMHO increasing the IF gain would not result in improved
receiver performance, as the FCD already suffers greatly from lack of
bandpass filters. Someone with more RF knowledge than myself may want
to comment on this, here is a diagram of the RF chain:
https://github.com/csete/qthid/blob/3.x/images/rfchain.png

If any other Funcube Dongle owners have different opinion or
experience, let us know!

Ultimately, the decision is not mine, but I think we should decide how
much of the FCD API we want to include and maintain.

Alex

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


Re: [Discuss-gnuradio] b100 error

2012-06-11 Thread Josh Blum


On 06/11/2012 10:51 AM, sumitstop wrote:
> 
> Hi Josh, 
> Did you update the code :-)

Alright, I am getting out my big hammer. Not only will this code be
fixed, but a new feature will be added!

-josh

> 
> Josh Blum-3 wrote:
>>
>>
>>>
>>> the SID keeps changing although .. While I saw I similar problem earlier
>>> in
>>> this
>>> thread(http://old.nabble.com/uhd-b100-problems-td33345827.html#a33345827 
>>> )
>>> but I am afraid that the problem still persists :( 
>>>
>>> my UHD version is uhd-images_003.004.001-109-g6ca39ad9
>>
>> This is an RX issue. I really swear I had nailed this down a while ago.
>> Do you mind trying an update?
>>
>> It looks like you are using the master branch.
>> I would update the host code and grab images here:
>> http://files.ettus.com/binaries/master_images/
>>
>> -josh
>>
>>>
>>> Thanks 
>>>
>>> -
>>> Sumit Kr.
>>> Research Assistant
>>> Communication Research center
>>> IIIT Hyderabad
>>> India
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
> 
> 
> -
> Sumit Kr.
> Research Assistant
> Communication Research center
> IIIT Hyderabad
> India

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


Re: [Discuss-gnuradio] Error Is OpenBTS going to support USRP2?

2012-06-11 Thread Ben Hilburn
OpenBTS works on USRP2s just fine.  You need to compile OpenBTS with host
resampling support, as the build instructions and your error log are
telling you.

http://wush.net/trac/rangepublic/wiki/BuildInstallRun

Cheers,
Ben

On Sat, Jun 9, 2012 at 12:52 AM, junaid124  wrote:

>
> muhammadjunaid@ubuntu:~/OpenBts/openbts-uhd/public-trunk/apps$ ./OpenBTS
>
>
> OpenBTS, Copyright 2008-2010 Free Software Foundation, Inc.
> Release 2.6PUBLIC built Apr 19 2012
> "OpenBTS" is a trademark of Kestrel Signal Processing, Inc.,
> regsitered with the US Patent and Trademark Office.
>
> Contributors:
>  Kestrel Signal Processing, Inc.:
>David Burgess, Harvind Samra, Raffi Sevlian, Roshan Baliga
>  GNU Radio:
>Johnathan Corgan
>  Others:
>Anne Kwong, Jacob Appelbaum, Joshua Lackey, Alon Levy
>Alexander Chemeris, Alberto Escudero-Pascual
> Incorporated GPL libraries and components:
>  libosip2, liportp2, readline
>
> This program comes with ABSOLUTELY NO WARRANTY.
>
> This is free software; you are welcome to redistribute it
> under the terms of AGPLv3.
> Please see the COPYING file in the source code for information
> about the AGPLv3 license and recommended procedures for compliance
> with the Affero requirements of that license.
>
> Use of this software may be subject to other legal restrictions,
> including patent licsensing and radio spectrum licensing.
> All users of this software are expected to comply with applicable
> regulations and laws.
>
>
> Starting the system...
> 1339182654.2386 ALARM 3074128576 OpenBTS.cpp:517:main: OpenBTS starting,
> ver
> 2.6PUBLIC build date Jun  6 2012
> linux; GNU C++ version 4.5.2; Boost_104200; UHD_003.004.000-1156d9b
>
> 1339182654.2560 FORCE 3052370400 Logger.cpp:196:gLogInit: Setting initial
> global logging level to NOTICE
> 1339182655.3935 ALARM 3052370400 UHDDevice.cpp:335:set_rates: Cannot set
> clock rate on this device
> 1339182655.3936 ALARM 3052370400 UHDDevice.cpp:336:set_rates: Please
> compile
> with host resampling support
> 1339182662.2433 ALARM 3065289584 TRXManager.cpp:90:clockHandler: TRX clock
> interface timed out, assuming TRX is dead.
> 1339182665.2448 ALARM 3065289584 TRXManager.cpp:90:clockHandler: TRX clock
> interface timed out, assuming TRX is dead.
> 1339182668.2481 ALARM 3065289584 TRXManager.cpp:90:clockHandler: TRX clock
> interface timed out, assuming TRX is dead.
> 1339182671.2508 ALARM 3065289584 TRXManager.cpp:90:clockHandler: TRX clock
> interface timed out, assuming TRX is dead.
> 1339182674.2541 ALARM 3065289584 TRXManager.cpp:90:clockHandler: TRX clock
> interface timed out, assuming TRX is dead.
> 1339182677.2574 ALARM 3065289584 TRXManager.cpp:90:clockHandler: TRX clock
> interface timed out, assuming TRX is dead.
> 1339182680.2589 ALARM 3065289584 TRXManager.cpp:90:clockHandler: TRX clock
> interface timed out, assuming TRX is dead.
> 1339182683.2622 ALARM 3065289584 TRXManager.cpp:90:clockHandler: TRX clock
> interface timed out, assuming TRX is dead.
> 1339182686.2628 ALARM 3065289584 TRXManager.cpp:90:clockHandler: TRX clock
> interface timed out, assuming TRX is dead.
> 1339182689.2631 ALARM 3065289584 TRXManager.cpp:90:clockHandler: TRX clock
> interface timed out, assuming TRX is dead.
> 1339182689.2726 ALARM 3074128576 TRXManager.cpp:273:sendCommandPacket:
> lost
> control link to transceiver
> 1339182689.2728 ALARM 3074128576 OpenBTS.cpp:672:main: Uncaught exception.
> Shutting down.
>
> exiting...
>
> --
> View this message in context:
> http://old.nabble.com/Is-OpenBTS-going-to-support-USRP2--tp22425805p33985231.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
>
> ___
> 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] Magnitude == RSSI?

2012-06-11 Thread Ben Hilburn
You shouldn't use the magnitude of the received samples as RSSI.The
magnitudes are generally in nondescript 'engineering units (dB)'.

If you want to calculate RSSI, Marcus Leech has posted a good solution a
few times in the past:

http://old.nabble.com/measuring-RSSI---N210-with-RFX2400-td31773654.html

Cheers,
Ben

On Sun, Jun 10, 2012 at 1:47 PM, Matthias Schäfer wrote:

> I've noticed that some dboards have RSSI sensors while others don't. Since
> I'm using a SBX (rev 3) which doesn't seem to have such a sensor, I'm
> wondering if it's also correct to use the magnitude of the samples as an
> indicator for the RSS or is this value somehow "distorted"?
>
> Cheers,
> Matthias
>
> __**_
> 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] NEC uPD720200 and USRP B100

2012-06-11 Thread Ben Hilburn
Vincenzo -

I have the exact same USB 3.0 controller:
0d:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller
(rev 04)

... on this Thinkpad 420s, and I have no issues using the B100.

Like Nick said, can you provide the output of:

$ sudo lspci -v
$ uname -a

Also, without making any changes, if you plug the B100 into a USB2.0 port,
it works fine?

Cheers,
Ben

On Mon, Jun 11, 2012 at 10:39 AM, Nick Foster  wrote:

> On Mon, Jun 11, 2012 at 10:28 AM, Vincenzo Pellegrini 
> wrote:
>
>> Hi Nick and everybody,
>>
>> today I tried to access my B100 via the NEC Corporation uPD720200
>> usb 3.0 controller that you quoted in this message:
>>
>> http://www.mail-archive.com/discuss-gnuradio@gnu.org/msg35877.html
>>
>> installed on a PCIe USB 3.0 expansion card.
>>
>> UHD could not find devices (./uhd_find_devices)
>>
>> whereas it actually can find my B100 both if it is connected to the USB
>> 2.0
>> controller on-board the PC motherboard and if it's connected to a PCI
>> USB 2.0 expansion card.
>>
>
> Mine's onboard, although it really shouldn't make a difference. Can you
> paste the output of lsusb and lspci -v?
>
> --n
>
>
>>
>> do you have any search hints for this, is your uPD720200 on-board the
>> motherboard or on a separate device?
>>
>> thanks and regards
>>
>> vincenzo
>>
>>
>> --
>> Vincenzo Pellegrini
>> http://www.youtube.com/user/wwvince1
>>
>
>
> ___
> 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] Error Is OpenBTS going to support USRP2?

2012-06-11 Thread Ben Hilburn
Muhammad -

The link I provided has a full list of the commands you need to run.

Cheers,
Ben

On Mon, Jun 11, 2012 at 1:43 PM, Muhammad JUNAID wrote:

> Please Provide me the command to compile with  host resampling support.
> thank you for response..
>
> JADE
>
>--
> *From:* Ben Hilburn 
> *To:* junaid124 
> *Cc:* Discuss-gnuradio@gnu.org
> *Sent:* Tuesday, June 12, 2012 12:59 AM
> *Subject:* Re: [Discuss-gnuradio] Error Is OpenBTS going to support USRP2?
>
> OpenBTS works on USRP2s just fine.  You need to compile OpenBTS with host
> resampling support, as the build instructions and your error log are
> telling you.
>
> http://wush.net/trac/rangepublic/wiki/BuildInstallRun
>
> Cheers,
> Ben
>
> On Sat, Jun 9, 2012 at 12:52 AM, junaid124  wrote:
>
>
> muhammadjunaid@ubuntu:~/OpenBts/openbts-uhd/public-trunk/apps$ ./OpenBTS
>
>
> OpenBTS, Copyright 2008-2010 Free Software Foundation, Inc.
> Release 2.6PUBLIC built Apr 19 2012
> "OpenBTS" is a trademark of Kestrel Signal Processing, Inc.,
> regsitered with the US Patent and Trademark Office.
>
> Contributors:
>  Kestrel Signal Processing, Inc.:
>David Burgess, Harvind Samra, Raffi Sevlian, Roshan Baliga
>  GNU Radio:
>Johnathan Corgan
>  Others:
>Anne Kwong, Jacob Appelbaum, Joshua Lackey, Alon Levy
>Alexander Chemeris, Alberto Escudero-Pascual
> Incorporated GPL libraries and components:
>  libosip2, liportp2, readline
>
> This program comes with ABSOLUTELY NO WARRANTY.
>
> This is free software; you are welcome to redistribute it
> under the terms of AGPLv3.
> Please see the COPYING file in the source code for information
> about the AGPLv3 license and recommended procedures for compliance
> with the Affero requirements of that license.
>
> Use of this software may be subject to other legal restrictions,
> including patent licsensing and radio spectrum licensing.
> All users of this software are expected to comply with applicable
> regulations and laws.
>
>
> Starting the system...
> 1339182654.2386 ALARM 3074128576 OpenBTS.cpp:517:main: OpenBTS starting,
> ver
> 2.6PUBLIC build date Jun  6 2012
> linux; GNU C++ version 4.5.2; Boost_104200; UHD_003.004.000-1156d9b
>
> 1339182654.2560 FORCE 3052370400 Logger.cpp:196:gLogInit: Setting initial
> global logging level to NOTICE
> 1339182655.3935 ALARM 3052370400 UHDDevice.cpp:335:set_rates: Cannot set
> clock rate on this device
> 1339182655.3936 ALARM 3052370400 UHDDevice.cpp:336:set_rates: Please
> compile
> with host resampling support
> 1339182662.2433 ALARM 3065289584 TRXManager.cpp:90:clockHandler: TRX clock
> interface timed out, assuming TRX is dead.
> 1339182665.2448 ALARM 3065289584 TRXManager.cpp:90:clockHandler: TRX clock
> interface timed out, assuming TRX is dead.
> 1339182668.2481 ALARM 3065289584 TRXManager.cpp:90:clockHandler: TRX clock
> interface timed out, assuming TRX is dead.
> 1339182671.2508 ALARM 3065289584 TRXManager.cpp:90:clockHandler: TRX clock
> interface timed out, assuming TRX is dead.
> 1339182674.2541 ALARM 3065289584 TRXManager.cpp:90:clockHandler: TRX clock
> interface timed out, assuming TRX is dead.
> 1339182677.2574 ALARM 3065289584 TRXManager.cpp:90:clockHandler: TRX clock
> interface timed out, assuming TRX is dead.
> 1339182680.2589 ALARM 3065289584 TRXManager.cpp:90:clockHandler: TRX clock
> interface timed out, assuming TRX is dead.
> 1339182683.2622 ALARM 3065289584 TRXManager.cpp:90:clockHandler: TRX clock
> interface timed out, assuming TRX is dead.
> 1339182686.2628 ALARM 3065289584 TRXManager.cpp:90:clockHandler: TRX clock
> interface timed out, assuming TRX is dead.
> 1339182689.2631 ALARM 3065289584 TRXManager.cpp:90:clockHandler: TRX clock
> interface timed out, assuming TRX is dead.
> 1339182689.2726 ALARM 3074128576 TRXManager.cpp:273:sendCommandPacket:
> lost
> control link to transceiver
> 1339182689.2728 ALARM 3074128576 OpenBTS.cpp:672:main: Uncaught exception.
> Shutting down.
>
> exiting...
>
> --
> View this message in context:
> http://old.nabble.com/Is-OpenBTS-going-to-support-USRP2--tp22425805p33985231.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
>
> ___
> 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] Patch to Include LNA enhancement and IF gain and filter settings for FCD

2012-06-11 Thread Bryan Biedenkapp
I agree about the IF RC Filter and IF Filter, I perhaps was a bit
overzealous when adding them. However, I do find being able to adjust the
IF Gain's to be useful when in noisy environments as a way of lowering the
gain (or increasing if necessary) even more beyond the the LNA and Mixer
stages.

-- 
Bryan Biedenkapp
GMRS Lic. WQDK979

+15db louder than "my ears are bleeding and I'm developing an aneurism".

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


[Discuss-gnuradio] N210 Unsuccessful Ref Lock

2012-06-11 Thread Ryan Wolfarth
Hi all,

My research group is continuing our setup of two servers with multiple
N210s for a GNSS application.  Each server will have 4 or 5 N210s recording
RF data at frequencies of interest.  All are to be locked to the 10MHz
reference and 1 PPS output from a Septentrio PolaRxS.  I have successfully
tested our PPS arrangement using test_pps_input.  However,
test_dboard_coercion sometimes reports an unsuccessful lock to our external
oscillator.  The number of unsuccessful locks varies with the inputs to
test_dboard_coercion:

Set1:  "--rx --ref external" reports an unsuccessful ref lock at 1500MHz
Set2:  "--rx --ref external --no_rx_gain" reports an unsuccessful ref lock
at 1500, 1550, 1700, 1750, 1800, 1850, 1900, 1950, and 2000MHz.

These unsuccessful locks are intermittent.  The results for Set2 don't
worry me so much: we're always running at high gain when recording.  What
is the cause and is there a good solution to this problem?  Our plan is to
have all N210s writing constantly to a ring buffer, but only writing to
file when triggered by an external source.  The reference lock is critical
since we're studying GNSS signals.  Any help is appreciated.  I know this
list usually hits it out of the park, so I'm looking forward to your
responses!

Thank you,
Ryan

Setup: Dell PowerEdge R510 running UHD 3.4.2 on Ubuntu 12.04 server.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] N210 Unsuccessful Ref Lock

2012-06-11 Thread Marcus D. Leech

Hi all,

My research group is continuing our setup of two servers with multiple 
N210s for a GNSS application.  Each server will have 4 or 5 N210s 
recording RF data at frequencies of interest.  All are to be locked to 
the 10MHz reference and 1 PPS output from a Septentrio PolaRxS.  I 
have successfully tested our PPS arrangement using test_pps_input.  
However, test_dboard_coercion sometimes reports an unsuccessful lock 
to our external oscillator.  The number of unsuccessful locks varies 
with the inputs to test_dboard_coercion:


Set1:  "--rx --ref external" reports an unsuccessful ref lock at 1500MHz
Set2:  "--rx --ref external --no_rx_gain" reports an unsuccessful ref 
lock at 1500, 1550, 1700, 1750, 1800, 1850, 1900, 1950, and 2000MHz.


These unsuccessful locks are intermittent.  The results for Set2 don't 
worry me so much: we're always running at high gain when recording.  
What is the cause and is there a good solution to this problem?  Our 
plan is to have all N210s writing constantly to a ring buffer, but 
only writing to file when triggered by an external source.  The 
reference lock is critical since we're studying GNSS signals.  Any 
help is appreciated.  I know this list usually hits it out of the 
park, so I'm looking forward to your responses!


Thank you,
Ryan

Setup: Dell PowerEdge R510 running UHD 3.4.2 on Ubuntu 12.04 server.


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

After splitting your 10Mhz reference, what is the power going to each N210?



--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

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


[Discuss-gnuradio] Where can I find the algorithms that were used to develop the synchronization blocks of gnuradio?

2012-06-11 Thread Nazmul Islam
Hello,

 I want to read the papers that were used to generate some of the
synchronization blocks of gnuradio. In particular, I need to understand the
following blocks:

1) Polyphase Resampler,
 2) FLL Band-Edge,
3) Polyphase Clock Synchonizer and
4) Costas Loop.

I think that the algorithms of some of these blocks were taken from Fred
Harris's multirate signal processing book. I have just ordered that book
from Amazon. I have also downloaded the "digital receivers and transmitters
using polyphase filter bank .." and "practical costas loop: designing a
simple and inexpensive costas loop ..." paper. Is there any other paper or
source that might help me?

Specially, it would be really helpful to find out the exact papers (or
parts of a book) that were used to develop each of these blocks. Any
suggestion will be appreciated.

Thanks,

Nazmul


-- 
Muhammad Nazmul Islam

Graduate Student
Electrical & Computer Engineering
Wireless Information & Networking Laboratory
Rutgers, USA.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] N210 Unsuccessful Ref Lock

2012-06-11 Thread Ryan Wolfarth
The clock signal has not been split yet: I'm only testing one N210 to
verify a reference lock.  We will be using a SRS FS735 distribution
amplifier for clock splitting.  It outputs 13+/-1 dBm to a 50 Ohm load from
each output.

The current dboard is an RFX1800, but we will be using a combination of
1200s and 1800s depending on the signal we're capturing.  We changed the
sleep time in test_dboard_coercion to 5 seconds instead of 1.  I'm going
perform some more thorough testing, but this looks like a good fix!

Thank you,
Ryan

On Mon, Jun 11, 2012 at 7:14 PM, Josh Blum  wrote:

>
>
> On 06/11/2012 04:04 PM, Ryan Wolfarth wrote:
> > Hi all,
> >
> > My research group is continuing our setup of two servers with multiple
> > N210s for a GNSS application.  Each server will have 4 or 5 N210s
> recording
> > RF data at frequencies of interest.  All are to be locked to the 10MHz
> > reference and 1 PPS output from a Septentrio PolaRxS.  I have
> successfully
> > tested our PPS arrangement using test_pps_input.  However,
> > test_dboard_coercion sometimes reports an unsuccessful lock to our
> external
> > oscillator.  The number of unsuccessful locks varies with the inputs to
> > test_dboard_coercion:
> >
> > Set1:  "--rx --ref external" reports an unsuccessful ref lock at 1500MHz
> > Set2:  "--rx --ref external --no_rx_gain" reports an unsuccessful ref
> lock
> > at 1500, 1550, 1700, 1750, 1800, 1850, 1900, 1950, and 2000MHz.
> >
> > These unsuccessful locks are intermittent.  The results for Set2 don't
> > worry me so much: we're always running at high gain when recording.  What
> > is the cause and is there a good solution to this problem?  Our plan is
> to
> > have all N210s writing constantly to a ring buffer, but only writing to
> > file when triggered by an external source.  The reference lock is
> critical
> > since we're studying GNSS signals.  Any help is appreciated.  I know this
> > list usually hits it out of the park, so I'm looking forward to your
> > responses!
> >
> > Thank you,
> > Ryan
> >
> > Setup: Dell PowerEdge R510 running UHD 3.4.2 on Ubuntu 12.04 server.
> >
> >
> >
>
> Ryan,
>
> Can you tell me which dboard you are using? Its possible the sleep time
> before checking for lock might not be enough.
>
> -Josh
>
> >
> > ___
> > 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] N210 Unsuccessful Ref Lock

2012-06-11 Thread Josh Blum


On 06/11/2012 05:18 PM, Ryan Wolfarth wrote:
> The clock signal has not been split yet: I'm only testing one N210 to
> verify a reference lock.  We will be using a SRS FS735 distribution
> amplifier for clock splitting.  It outputs 13+/-1 dBm to a 50 Ohm load from
> each output.
> 
> The current dboard is an RFX1800, but we will be using a combination of
> 1200s and 1800s depending on the signal we're capturing.  We changed the
> sleep time in test_dboard_coercion to 5 seconds instead of 1.  I'm going
> perform some more thorough testing, but this looks like a good fix!
> 

Yea, sorry. It looks like there were a few things a little screwy with
the lock detect checking. I will push something tomorrow to make it a
little more consistent.

Thanks!
-Josh

> Thank you,
> Ryan
> 
> On Mon, Jun 11, 2012 at 7:14 PM, Josh Blum  wrote:
> 
>>
>>
>> On 06/11/2012 04:04 PM, Ryan Wolfarth wrote:
>>> Hi all,
>>>
>>> My research group is continuing our setup of two servers with multiple
>>> N210s for a GNSS application.  Each server will have 4 or 5 N210s
>> recording
>>> RF data at frequencies of interest.  All are to be locked to the 10MHz
>>> reference and 1 PPS output from a Septentrio PolaRxS.  I have
>> successfully
>>> tested our PPS arrangement using test_pps_input.  However,
>>> test_dboard_coercion sometimes reports an unsuccessful lock to our
>> external
>>> oscillator.  The number of unsuccessful locks varies with the inputs to
>>> test_dboard_coercion:
>>>
>>> Set1:  "--rx --ref external" reports an unsuccessful ref lock at 1500MHz
>>> Set2:  "--rx --ref external --no_rx_gain" reports an unsuccessful ref
>> lock
>>> at 1500, 1550, 1700, 1750, 1800, 1850, 1900, 1950, and 2000MHz.
>>>
>>> These unsuccessful locks are intermittent.  The results for Set2 don't
>>> worry me so much: we're always running at high gain when recording.  What
>>> is the cause and is there a good solution to this problem?  Our plan is
>> to
>>> have all N210s writing constantly to a ring buffer, but only writing to
>>> file when triggered by an external source.  The reference lock is
>> critical
>>> since we're studying GNSS signals.  Any help is appreciated.  I know this
>>> list usually hits it out of the park, so I'm looking forward to your
>>> responses!
>>>
>>> Thank you,
>>> Ryan
>>>
>>> Setup: Dell PowerEdge R510 running UHD 3.4.2 on Ubuntu 12.04 server.
>>>
>>>
>>>
>>
>> Ryan,
>>
>> Can you tell me which dboard you are using? Its possible the sleep time
>> before checking for lock might not be enough.
>>
>> -Josh
>>
>>>
>>> ___
>>> 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] Registering Custom Data Types

2012-06-11 Thread Ryan Wolfarth
Hi again,

The "device streaming" documentation mentions that users may register their
own data types and converter routines.  I'd like to implement a converter
that takes the sc8 data type from the wire and converts to an sc8 host data
type.  It looks like Josh added this functionality in November of last
year.  Could I make use of this converter in rx_samples_to_file?  If so,
can you provide an example of general converter use?  This is also cited as
"todo" in the "Device streaming" documentation.

Thank you,
Ryan

Setup: Dell PowerEdge R510 running UHD 3.4.2 on Ubuntu 12.04 server.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio