[Discuss-gnuradio] UHD Announcement - January 20th 2011

2011-01-20 Thread Josh Blum
Hello list,

The UHD work in the next branch has been merged into the master. These
changes include new FPGA and firmware images, changes uhd host code, and
changes to gnuradio gr-uhd.

-
-- FPGA and firmware images
-
New images are required for all USRP products except for the USRP1
classic (which has not changed).

Upgrading N210 images is a new thing for USRP users. Make sure to burn
both the FPGA and the firmware image before power cycling. If you get it
wrong or mess up, you can always boot into the safe mode and try again.
*Do not overwrite the safe mode images.*

Instructions here:
http://www.ettus.com/uhd_docs/manual/html/usrp2.html#load-the-images-onto-the-on-board-flash-usrp-n-series-only

Most recent images available here:
http://www.ettus.com/downloads/uhd_images/UHD-images-most-recent/

-
-- API changes
-
The API compat number has been incremented from 1 to 2. The change was
necessary to ensure compatibility with new features in gr-uhd. But,
nothing has changed from an API perspective that would cause code out
there to break.

One obvious change is that the range types and gains are now all of type
double. By only using type double, I could simplify the ranges types,
get rid of some temple nonsense and in short, UHD will build and run
under the clang compiler.

A new call, get time at last pps has been added. Users may query this
function to determine that their device is indeed getting the PPS
signal. It also simplifies coordinating a synchronization across
multiple devices when the PPS edge is unknown to the host. See

http://www.ettus.com/uhd_docs/doxygen/html/classuhd_1_1usrp_1_1multi__usrp.html#a79a5472fc16ab9723781c8cdae0bdf00

http://www.ettus.com/uhd_docs/doxygen/html/classuhd_1_1usrp_1_1multi__usrp.html#a413014bf3aea4a8ea2d268b4a3b390e9


-
-- gr-uhd features
-
Most of these changes involved bringing existing c++ features into
python land. This includes:

* device discovery and enumeration
* devices addresses swigged up
* types are now printable, think __str__ and __repr__
* the _t suffix on the uhd types is now optional

-
-- USRP2 + N series MIMO cable support
-
MIMO cable support has now been integrated. In short, the MIMO cable
provides time and clock reference synchronization, and can optionally
share a data path between devices.

Basic usage notes detailed here:
http://www.ettus.com/uhd_docs/manual/html/usrp2.html#using-the-mimo-cable

-
-- USRP1 feature emulation
-
The USRP1 classic lacks many of the time-based streaming features found
in the newer devices. Ex: If you tell the USRP1 to stream N samples at
time t, it will throw an error. Many of the missing streaming features
have now been implemented in software, and as a result, most of the
examples in UHD now work with USRP1.

The following details the features:
http://www.ettus.com/uhd_docs/manual/html/usrp1.html#missing-and-emulated-features

I will throw this out there as a little challenge. With these features
implemented, the OpenBTS+UHD port on USRP1 will probably run without
error, but will it _work_ (as in talk to a gsm phone)?
Just a curiosity...

-
Feedback is welcome!

Thanks,
-Josh

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


Re: [Discuss-gnuradio] UHD Announcement - January 20th 2011

2011-01-20 Thread Moritz Fischer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/20/2011 09:05 AM, Josh Blum wrote:

> [...] UHD will build and run under the clang compiler.

Cool stuff! Thanks Josh :-)

Cheers,
Moritz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJNN/UPAAoJEOjnDXL6I0uZRqcP/1pU/Wf6XujpPRwKqu1stLz6
+9uLMnid53Vekl6nUkOFaJQaG8Rtm2+pqBqKAujhQqbp3jjRitkJ42/6Yl4y8UAc
CDc8y7qLBSE/SdrnhQR5TkvROnpu6MkDvEoEYciVbvJ0n9gcpGAA+ptTL65LjoKh
N9DPkY98UhJFjrf0Iocnajv8IM6TGb9+u9cpkmD2OqGh0npnJjHd3sHFE5q5fSoM
jUmNDCROVj0DdfFb+rNB7QfDOuZDfbVRzM01eqYUIDxhxdpZsfIZkLkt3qaPjipS
Pus6SYjFFiEQbz4qxAo+iPlfUXAqLaTY8ZRA7ag04kLYkipAIrxXmwMQSm9D4bHi
+95Vd6h1Uw2Rq8PAFeqfFAi+Nwajy1z+C1zLnMgAWdAXlX7V+AOE7eJujSgLjhZG
qs3lyPy4P+x297dH/f+L/ed+dKGvMCILnD3ykbI1ex5RpjrO/mxOrAZldXt1Y9VM
eyItn1wyY4nQ4k3JN5CkhoSAnfEFqW/Cz5ekzuUnarmc8JfyZbrR00IN3/Kt5KOD
BjM02Ll6n+oAUeN8IhoC6ub7HNrZAiFZrIODmmdB9R4UpzL3OqyWcccKDvzYwSrv
f22aHBu8YwwPEgHyQKeuYCBui7Iyk+wfyLTDYGLP5FJDfuxOH6qg6t67GMyhX7vC
PSdlJpDzdlaADKBP8IUB
=5bvg
-END PGP SIGNATURE-

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


Re: [Discuss-gnuradio] Mail with picture

2011-01-20 Thread Moritz Fischer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/19/2011 08:01 PM, Gabriel Morel wrote:
> Do you know how can I send a email with pictures.  I just tried to send one 
> and he was fired.

Just upload it somewhere and send a link. Like this the people that want
to see it can see it, while the others save time and bandwidth.

Moritz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJNN/YvAAoJEOjnDXL6I0uZXuEQAIgD9JdtBt3C7mHxXOIH0gU8
q0yMtvcIGdi9fDg6SikoEKfqggbcHV+OLsMLXjSssPy+818fPj3P7dt81+1X0hjM
0rm+yzRDeMDJZgmT5ivcPz34TG3qzXVlGikpCG3UPNPAylD4OgSn/8QLKRjn2Gpn
dJCK07DUJ5nNJtlC/alevRrmcG9h5vdtCpu0zHDazRb/A+SzgQGRtH1iMHc+FF12
o05Vgo+3T4G/K7b3FqNhVVUAKFtJ48+ixkM1dUb3pvu/lml8V32c+jqQEayzPhGc
RZKrN363SKBUS8q5wSpnBCnne3IFLEq6Sp1bw5JIn2k71kLe4EAvLfftQ7hJb8oO
ibKXC3udliMl0MkdAjXFWdxSMqHqPQasVdCesRdtKsjCSsb+LOG8hVYBd/m7JCqQ
eYQaIAfK9/MWICYjhIJZk/M8NyZOXoeCT1X4njanhihJMXzuAXQT+MIuoPuHyBa2
qdFY7kZ1wEo+3+wGV8MVG15vxuqnNbdlicXTGnucMmxoGgcTryDfL5KPQskW8xUJ
GFiYlSr42Nf9H06BkAfdE1I1O/xgaw2t5ZJ6dnc82wjUMGkhkjwTcINg7T+BxX9h
5AQ5POq8Ew2vHbrLq2jd4KKYLso0sddvzNSaflU5vm4moEoAALNdNj38z+sf3/yX
gu2eihh7oCTSBlRs8zbn
=a3Jr
-END PGP SIGNATURE-

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


Re: [Discuss-gnuradio] constellation object

2011-01-20 Thread Martin Braun
On Wed, Jan 19, 2011 at 11:55:30AM -0700, Ben Reynwar wrote:
> I'm new to all this, so I don't have a good handle on soft versus hard
> decision making.  My understanding is that a hard decision maker
> simply returns the symbol value, and a soft decision maker would
> return probabilities for various symbols values.  Then this
> probabilistic information would be interpreted by the decoder which
> would make the hard decision for sets of symbols simultaneously.  I
> don't understand what receiver_cf is doing if it returning a stream of
> floats.

You've got that right: a soft decider doesn't really decide, but rather
gives a value how good the estimate is. Say you have a binary output,
1 and -1. A soft decider can also give any value in between. If you get
a 0, then the soft decider really has no clue what was actually
transmitted and instead of guessing a binary value, it relays this
uncertainty.
One place this is really important is the channel decoding.

> On a related note, I've read that the minimum euclidean distance
> minimizes the chance of error if you have white gaussian noise.  Is
> this always a sensible assumption or are there practical situations in
> which a different measure would be better?  If not, then the distance
> could be used as a proxy for probability.  If others measures are
> sometimes better, then it would be nice to keep things more general.

Just a couple of euro-cents I'd like to add:
- White noise is a perfectly valid assumption. In most cases, your noise
  is WGN-ish anyway. If it isn't, then the constellation demodulator is
  not the right place to handle it, you'd use some kind of pre-whitening
  filter a priori.
- I'd say if you have to implement a soft- and hard-decider for each
  constellation anyway, you're general enough. With the aforementioned
  point, this means the hard decider is sіmply always the minimum
  euclidean distance, as you said already.
- After having a quick peek at your code, I wasn't quite sure if you've
  thought of differential PSKs?

All that aside, I think this is a good approach. GNU Radio currently has
a lot of fantastic DЅP code; what I miss is more structure, and I'm glad
to hear about the plans to refactor the digital stuff.

Cheers,
MB

-- 
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association



pgp9ZW1uRj6XX.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] Yet another kick at the cheap-hardware can

2011-01-20 Thread Euripedes Rocha Filho
Hi,
I'm very intersted in this project and will help to make things happen. I
can help in any part of the design, but I have more experience in FPGA
developing.

Euripedes

2011/1/20 Marcus D. Leech 

>  Hi Marcus,
> Who works on this project now?
>
> Nobody, really, except that I've posted a few "straw man" designs.
>
> Why choose USB as the interface to host. The USB interface became the
> bandwidth bottleneck
> in USRP1, so why use network interface?
>
> USB-2.0 is relatively cheap to implement, which is *one* of the project
> goals.
>
> Using 8-bit samples, you can achieve roughly 16Msps.  Using 4-bit samples,
> you can do better.
>   4-bit samples reduces your dynamic range, but for certain high-bandwidth
> applications, that's
>   OK.
>
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] Yet another kick at the cheap-hardware can

2011-01-20 Thread Mark Steward
On Wed, Jan 19, 2011 at 11:23 PM, Marcus D. Leech  wrote:
> If the answer to the above is "yes", then the next question is:  is
> there a community of interested
>  volunteers to bring the project to fruition?  Such an interested
> community would involve:
>
>     o High-level hardware design
>     o Detailed schematic capture and PCB layout
>     o FPGA firmware design
>     o Host-interface (FX2?) firmware design
>     o Host driver software design and implementation
>     o Small-scale financial investment for initial PCBs, components, etc
>

I have no knowledge of radio design beyond block diagrams, but I'm
very interested in this project as the sort of device every community
workshop or school should be able to get hold of.  I'm happy to
prototype PCBs and devices locally and help on the software
interfacing side.

Mark

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


[Discuss-gnuradio] Unwanted signal transmitted RFX900

2011-01-20 Thread Paco Quiñoy


Hi all,

Making some tests I have found that my system (USRP + RFX900) transmits an 
important signal (it seems a tone) without any application running, just when I 
plug the power source it transmits this unwanted signal. I'm working at the 
GSM900 downlink frequency band (between 935 and 960 MHz) and the signal appears 
close to the upper side of this band, around 959,6 Mhz. 

My system makes an spectrum sensing for that band and it locates the present 
signals, so it produces an error because it detects this undesired signal 
generated by itself. Any idea of the problem? Any solution?

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


[Discuss-gnuradio] UHD won't work with GRC

2011-01-20 Thread Fabian Klaes
Dear list,

i somehow can't get the UHD working with GRC. Detecting an USRP2 with
uhd_find_devices works just fine.
I am building from git (master) (what should include the UHD since today.
I'm also seeing the gr-uhd directory.)
I think that the issue is with ./configure, because there i can't find
gr-uhd when ./configure is finished. It prints:

*
The following components were skipped either because you asked not
to build them or they didn't pass configuration checks:

usrp2-firmware

These components will not be built.


*
The following GNU Radio components have been successfully configured:

config
gruel
gnuradio-core
usrp
usrp2
gr-usrp
gr-usrp2
gr-msdd6000
gr-audio-alsa
gr-audio-oss
gr-atsc
gr-cvsd-vocoder
gr-gpio
gr-gsm-fr-vocoder
gr-noaa
gr-pager
gr-radar-mono
gr-radio-astronomy
gr-trellis
gr-video-sdl
gr-wxgui
gr-qtgui
gr-sounder
gr-utils
gnuradio-examples
grc
docs

You my now run the make command to build these components.

*
The following components were skipped either because you asked not
to build them or they didn't pass configuration checks:

gcell
gr-gcell
gr-audio-jack
gr-audio-osx
gr-audio-portaudio
gr-audio-windows
gr-comedi

These components will not be built.

Configured GNU Radio release v3.3.1git-144-gf294603d for build.



But gr-uhd is neither in the components that will be build, nor in those,
that won't be build.

I also tried ./configure --enable-gr-uhd but that didn't change a thing :-(


If you got any ideas on how to proceed, please let me know.

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


Re: [Discuss-gnuradio] UHD won't work with GRC

2011-01-20 Thread Alexandru Csete
On Thu, Jan 20, 2011 at 2:51 PM, Fabian Klaes  wrote:
> Dear list,
>
> i somehow can't get the UHD working with GRC. Detecting an USRP2 with
> uhd_find_devices works just fine.
> I am building from git (master) (what should include the UHD since today.
> I'm also seeing the gr-uhd directory.)

The merging of next -> master was announced for UHD, not for GNU
Radio. You need:
UHD master branch
GNU Radio next branch
see http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/wiki


> I think that the issue is with ./configure, because there i can't find
> gr-uhd when ./configure is finished. It prints:
>
> *
> The following components were skipped either because you asked not
> to build them or they didn't pass configuration checks:
>
> usrp2-firmware
>
> These components will not be built.
>
>
> *
> The following GNU Radio components have been successfully configured:
>
> config
> gruel
> gnuradio-core
> usrp
> usrp2
> gr-usrp
> gr-usrp2
> gr-msdd6000
> gr-audio-alsa
> gr-audio-oss
> gr-atsc
> gr-cvsd-vocoder
> gr-gpio
> gr-gsm-fr-vocoder
> gr-noaa
> gr-pager
> gr-radar-mono
> gr-radio-astronomy
> gr-trellis
> gr-video-sdl
> gr-wxgui
> gr-qtgui
> gr-sounder
> gr-utils
> gnuradio-examples
> grc
> docs
>
> You my now run the make command to build these components.
>
> *
> The following components were skipped either because you asked not
> to build them or they didn't pass configuration checks:
>
> gcell
> gr-gcell
> gr-audio-jack
> gr-audio-osx
> gr-audio-portaudio
> gr-audio-windows
> gr-comedi
>
> These components will not be built.
>
> Configured GNU Radio release v3.3.1git-144-gf294603d for build.

This number is for the master branch. The correct revision id for the
next branch is (was earlier today) v3.3.1git-865-gd429522


> But gr-uhd is neither in the components that will be build, nor in those,
> that won't be build.
>
> I also tried ./configure --enable-gr-uhd but that didn't change a thing :-(
>
>
> If you got any ideas on how to proceed, please let me know.
>

Aside from using the correct GNU Radio branch (next) you also need to
install UHD first, otherwise the GNU Radio configure script will not
detect it and will skip it.

Alex

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


Re: [Discuss-gnuradio] Help : Can we use the c++ part of the gnuradio only.

2011-01-20 Thread Tom Rondeau
On Thu, Jan 20, 2011 at 2:41 AM, ton ph  wrote:
> HI everyone ,
>   I want to know a thing regarding gnuradio to all the guys out there
> regarding the gnuradio implementation using the c++ programming only.
> What i mean to say is that i want to use c++ part of the gnuradio and remove
> the python part in my experiment regarding the signal processing blocks.
> I want my code to be programmed in c++programming and not using the
> python.My signal processing block is in c++.
> Thanks in advance for your concern , and hope someone will guide me in this
> topic.

You can find a simple example in the source code at
gnuradio-examples/c++/dial_tone.

You can also completely disable python if you want during configure
time using the --disable-python flag.

Tom

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


Re: [Discuss-gnuradio] Yet another kick at the cheap-hardware can

2011-01-20 Thread William Cox
I don't know if this is kosher, but has anyone looked at the (vast array of)
offerings from Comblocks (comblock.com)? They sell FPGA IP cores for all of
their hardware, and it seems like it might be a good match for building a
basic I/Q acquisition system. Here's a full product list:
http://comblock.com/product_list.html
 The block diagram at the bottom of
this page gives an idea of how things could work:
http://comblock.com/com8002.html
 -William


On Thu, Jan 20, 2011 at 6:05 AM, Mark Steward  wrote:

> On Wed, Jan 19, 2011 at 11:23 PM, Marcus D. Leech 
> wrote:
> > If the answer to the above is "yes", then the next question is:  is
> > there a community of interested
> >  volunteers to bring the project to fruition?  Such an interested
> > community would involve:
> >
> > o High-level hardware design
> > o Detailed schematic capture and PCB layout
> > o FPGA firmware design
> > o Host-interface (FX2?) firmware design
> > o Host driver software design and implementation
> > o Small-scale financial investment for initial PCBs, components, etc
> >
>
> I have no knowledge of radio design beyond block diagrams, but I'm
> very interested in this project as the sort of device every community
> workshop or school should be able to get hold of.  I'm happy to
> prototype PCBs and devices locally and help on the software
> interfacing side.
>
> Mark
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] UHD won't work with GRC

2011-01-20 Thread Fabian Klaes
First of all, thank you for your advice.
Now i encountered another Problem:
At first i updated UHD via git pull, then i did (from the "build" directory)
cmake ../
make
make test
sudo make install

everything works fine (well, not everything, but at least the installation
;-) ).

Then i went to my gnuradio directory and did:
git checkout next
git clean -xf
git pull

# GNU Radio release is now v3.3.1git-865-gd429522b instead of
v3.3.1git-865-gd429522, but this should be newer

export LD_LIBRARY_PATH=$BOOST_PREFIX/lib
./bootstrap
./configure --with-boost=$BOOST_PREFIX

# ./configure now includes gr-uhd, so this problem is solved. Thanks again!

make

Then, make fails with:
Making install in swig
make[5]: Betrete Verzeichnis '/home/fs/gnuradio-git/gnuradio/usrp/host/swig'
make  install-am
make[6]: Betrete Verzeichnis '/home/fs/gnuradio-git/gnuradio/usrp/host/swig'
make[6]: *** Keine Regel vorhanden, um das Target »usrp_prims.cc«,
  benötigt von »_usrp_prims_la-usrp_prims.lo«, zu erstellen.  Schluss.
make[6]: Verlasse Verzeichnis
'/home/fs/gnuradio-git/gnuradio/usrp/host/swig'
make[5]: *** [install] Fehler 2
make[5]: Verlasse Verzeichnis
'/home/fs/gnuradio-git/gnuradio/usrp/host/swig'
make[4]: *** [install-recursive] Fehler 1
make[4]: Verlasse Verzeichnis '/home/fs/gnuradio-git/gnuradio/usrp/host'
make[3]: *** [install-recursive] Fehler 1
make[3]: Verlasse Verzeichnis '/home/fs/gnuradio-git/gnuradio/usrp'
make[2]: *** [install] Fehler 2
make[2]: Verlasse Verzeichnis '/home/fs/gnuradio-git/gnuradio/usrp'
make[1]: *** [install-recursive] Fehler 1
make[1]: Verlasse Verzeichnis '/home/fs/gnuradio-git/gnuradio'
make: *** [install] Fehler 2

Sorry, that it's in german, heres the translation:
Betrete Verzeichnis = Entering directory
Verlasse Verzeichnis = Leaving directory
Fehler = Error

And the (probably) critical part causing the error:
make[6]: *** Keine Regel vorhanden, um das Target »usrp_prims.cc«,
  benötigt von »_usrp_prims_la-usrp_prims.lo«, zu erstellen.  Schluss.
make[6]: *** No Rule given, for making Target »usrp_prims.cc«,
  needed by »_usrp_prims_la-usrp_prims.lo«.  Ending.


If you (or anyone else) got another hint on how to solve this i would be
really glad.

Thanks again and in advance

Fabian




On Thu, Jan 20, 2011 at 3:11 PM, Alexandru Csete  wrote:

> On Thu, Jan 20, 2011 at 2:51 PM, Fabian Klaes 
> wrote:
> > Dear list,
> >
> > i somehow can't get the UHD working with GRC. Detecting an USRP2 with
> > uhd_find_devices works just fine.
> > I am building from git (master) (what should include the UHD since today.
> > I'm also seeing the gr-uhd directory.)
>
> The merging of next -> master was announced for UHD, not for GNU
> Radio. You need:
> UHD master branch
> GNU Radio next branch
> see http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/wiki
>
>
> > I think that the issue is with ./configure, because there i can't find
> > gr-uhd when ./configure is finished. It prints:
> >
> > *
> > The following components were skipped either because you asked not
> > to build them or they didn't pass configuration checks:
> >
> > usrp2-firmware
> >
> > These components will not be built.
> >
> >
> > *
> > The following GNU Radio components have been successfully configured:
> >
> > config
> > gruel
> > gnuradio-core
> > usrp
> > usrp2
> > gr-usrp
> > gr-usrp2
> > gr-msdd6000
> > gr-audio-alsa
> > gr-audio-oss
> > gr-atsc
> > gr-cvsd-vocoder
> > gr-gpio
> > gr-gsm-fr-vocoder
> > gr-noaa
> > gr-pager
> > gr-radar-mono
> > gr-radio-astronomy
> > gr-trellis
> > gr-video-sdl
> > gr-wxgui
> > gr-qtgui
> > gr-sounder
> > gr-utils
> > gnuradio-examples
> > grc
> > docs
> >
> > You my now run the make command to build these components.
> >
> > *
> > The following components were skipped either because you asked not
> > to build them or they didn't pass configuration checks:
> >
> > gcell
> > gr-gcell
> > gr-audio-jack
> > gr-audio-osx
> > gr-audio-portaudio
> > gr-audio-windows
> > gr-comedi
> >
> > These components will not be built.
> >
> > Configured GNU Radio release v3.3.1git-144-gf294603d for build.
>
> This number is for the master branch. The correct revision id for the
> next branch is (was earlier today) v3.3.1git-865-gd429522
>
>
> > But gr-uhd is neither in the components that will be build, nor in those,
> > that won't be build.
> >
> > I also tried ./configure --enable-gr-uhd but that didn't change a thing
> :-(
> >
> >
> > If you got any ideas on how to proceed, please let me know.
> >
>
> Aside from using the correct GNU Radio branch (next) you also need to
> install UHD first, otherwise the GNU Radio configure script will not
> detect it and will skip it.
>
> Alex
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/ma

Re: [Discuss-gnuradio] Yet another kick at the cheap-hardware can

2011-01-20 Thread Euripedes Rocha Filho
Well, may be an option for someone , but we are trying to get a cheaper, and
open-source, hardware and I hope we can do this.

Euripedes

2011/1/20 William Cox 

> I don't know if this is kosher, but has anyone looked at the (vast array
> of) offerings from Comblocks (comblock.com)? They sell FPGA IP cores for
> all of their hardware, and it seems like it might be a good match for
> building a basic I/Q acquisition system. Here's a full product list:
> http://comblock.com/product_list.html
>  The block diagram at the bottom of
> this page gives an idea of how things could work:
> http://comblock.com/com8002.html
>  -William
>
>
> On Thu, Jan 20, 2011 at 6:05 AM, Mark Steward wrote:
>
>> On Wed, Jan 19, 2011 at 11:23 PM, Marcus D. Leech 
>> wrote:
>> > If the answer to the above is "yes", then the next question is:  is
>> > there a community of interested
>> >  volunteers to bring the project to fruition?  Such an interested
>> > community would involve:
>> >
>> > o High-level hardware design
>> > o Detailed schematic capture and PCB layout
>> > o FPGA firmware design
>> > o Host-interface (FX2?) firmware design
>> > o Host driver software design and implementation
>> > o Small-scale financial investment for initial PCBs, components, etc
>> >
>>
>> I have no knowledge of radio design beyond block diagrams, but I'm
>> very interested in this project as the sort of device every community
>> workshop or school should be able to get hold of.  I'm happy to
>> prototype PCBs and devices locally and help on the software
>> interfacing side.
>>
>> Mark
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] Greeting and a question

2011-01-20 Thread Sanjay Singh
Hi all,

Am disappointed with the way GNURadio is getting into.

I see all the discussion around is to promote the products of Ettus
Research.

Agreed!. Great work from Ettus Research.

But there are many boards available which are far better in capability vs
price. I don't want to mention them here to deviate the concern.

During the market for USRP1, no one in the forum focused discussion on
embedded platform. When queries regarding any such embedded platform was
posted, there were lot of quotes saying GNURadio is focused on developing
SDR framework based on Desktop based solution. With Ettus Research coming
out with USRP E100, everyone on is bouncing on embedded platform.

I wonder; Is GNURadio biased with Ettus Reserch ?. My obvious understanding
is NO!.

Its the community of people driving Ettus products into market. The
potential of doing so is to make money. Either way, Ettus Research is now
part of National Instruments and may be now GNURadio be delinked with Ettus
Research for being open source. There are many people who can contribute low
cost open source solutions.

Initially, all the Hardware and software was part of GNURadio. All the files
was part of free source available to download and use. In around a year or
so all the files from GNURadio were moved out separating hardware and
software. All the hardware related files were not available after this. Why
so, no one knows.

The boards when purchased from Ettus Research it was under terms and
conditions as free open source schematics for motherboard and free open
source schematics and pcb files.

Its time now for the community of people interested in building free open
source platform including both software and Hardware to come out with an
complete open source low cost solution.

S---




On Wed, Jan 19, 2011 at 3:05 PM, Farhad Abdolian wrote:

> HI Tom,
> I am afraid not, first of all OMAP is under export restriction from the US
> government that means it can not be sold (or should not be sold) without US
> export control.
> Second, this board is a nice toy, but I can not justify $1300 for the
> functionality that E100 gives.
>
> Best regards,
> Farhad
>
> --
> *From:* Tom Rondeau 
> *To:* Farhad Abdolian 
> *Cc:* discuss-gnuradio@gnu.org
> *Sent:* Mon, January 17, 2011 6:27:40 PM
>
> *Subject:* Re: [Discuss-gnuradio] Greeting and a question
>
> That sounds like a reasonable approach.
>
> When you're ready, you should probably look at the Ettus USRP-E100,
> which uses an ARM-based OMAP processor. That seems like it's pretty
> much the form-factor you are looking for.
>
> Tom
>
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] UHD won't work with GRC

2011-01-20 Thread Josh Blum

> And the (probably) critical part causing the error:
> make[6]: *** Keine Regel vorhanden, um das Target »usrp_prims.cc«,
>   benötigt von »_usrp_prims_la-usrp_prims.lo«, zu erstellen.  Schluss.
> make[6]: *** No Rule given, for making Target »usrp_prims.cc«,
>   needed by »_usrp_prims_la-usrp_prims.lo«.  Ending.
> 
> 
> If you (or anyone else) got another hint on how to solve this i would be
> really glad.
> 

Sometimes autotools gets confused when there are many changes to the
build system. Try make distclean, and if not working: git clean -dfx
(wipes everything). and rebuild from scratch.

-Josh

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


Re: [Discuss-gnuradio] filename using time-stamp in GRC

2011-01-20 Thread Josh Blum
If you created a custom block in python that would do the right thing as
far as writing the file and handling the data; then you could use the
variable chooser (button) or variable text box (string input) to
generate the event.

-Josh

On 01/19/2011 10:47 AM, emat...@yahoo.com wrote:
> He all-
> 
> is there a way to implement a button controlling a record-to-file function 
> where the filename is generated instantly from the current time stamp?  I can 
> do this manually in python as follows (taken from a previously existing 
> gnuradio code):
> 
> #
> # Recording file, in case we ever need to record baseband data
> #
> self.recording = gr.file_sink(gr.sizeof_float, "/dev/null")
> self.recording_state = False
> # Filename prefix for recording file
> self.prefix = options.prefix
> 
> # We come up with recording turned off, but the user may
> #  request recording later on
> self.recording.close()
> 
> .
> .
> .
> 
>   self.connect (self.source, self.recording)
> 
> .
> .
> .
> 
> # Data recording control
> buttonbox = wx.BoxSizer(wx.HORIZONTAL)
> self.record_control = form.button_with_callback(self.panel,
>   label="Recording Data: Off  
>  ",
>   callback=self.toggle_recording)
> 
> buttonbox.Add(self.record_control, 0, wx.CENTER)
> 
> .
> .
> .
> 
> #
> # Turn recording on/off
> # Called-back by "Recording" button
> #
> def toggle_recording(self):
> # Pick up localtime, for generating filenames
> timestamp = time.localtime()
> 
> # Generate filenames for both data and header file
> filename = "%04d_%02d_%02d_%02d:%02d:%02d.dat" % (timestamp.tm_year, 
> timestamp.tm_mon,
> timestamp.tm_mday, timestamp.tm_hour, 
> timestamp.tm_min,timestamp.tm_sec)
> 
> # Current recording?  Flip state
> if (self.recording_state == True):
>   self.recording_state = False
>   self.record_control.SetLabel("Recording Data: Off   
>  ")
>   self.recording.close()
> # Not recording?
> else:
>   self.recording_state = True
>   self.record_control.SetLabel("Recording Data to: "+filename)
> 
>   # Cause gr_file_sink object to accept new filename
>   #   note use of self.prefix--filename prefix from
>   #   command line (defaults to ./)
>   #
>   self.recording.open (self.prefix+filename)
> 
> 
> Thanks!
> eric
> 
> 
> 
>   
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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


[Discuss-gnuradio] WBX - only real signal after some time

2011-01-20 Thread Ruben Undheim
Hello.

I just wondered if anyone else has experienced that the WBX stops sending
the quadrature component of the complex signal after a while. This happens
especially if I have sliders for setting the frequencies or the gain, and
the sliders are slided. (so that a frequency change control signal is sent
several times successively)
In an FFT-sink, this is observed as a display mirrored around the base
frequency.

I have not found any other solution to fix this than to restart the whole
program every time it happens. This has never happened when using the TVRX
board.

I wonder if this is normal for these daughterboards, and that one just has
to ensure that they do not get a lot of frequency setting control messages
successively, or if there is a workaround.


Ruben
 (using USRP1)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] filename using time-stamp in GRC

2011-01-20 Thread ematlis


--- On Wed, 1/19/11, emat...@yahoo.com  wrote:

> From: emat...@yahoo.com 
> Subject: [Discuss-gnuradio] filename using time-stamp in GRC
> To: discuss-gnuradio@gnu.org
> Date: Wednesday, January 19, 2011, 12:47 PM
> He all-
> 
> is there a way to implement a button controlling a
> record-to-file function where the filename is generated
> instantly from the current time stamp?  I can do this
> manually in python as follows (taken from a previously
> existing gnuradio code):
> 
>         #
>         # Recording file, in case we
> ever need to record baseband data
>         #
>         self.recording =
> gr.file_sink(gr.sizeof_float, "/dev/null")
>         self.recording_state = False
>         # Filename prefix for recording
> file
>         self.prefix = options.prefix
> 
>         # We come up with recording
> turned off, but the user may
>         #  request recording later
> on
>         self.recording.close()
> 
> .
> .
> .
> 
>     self.connect (self.source,
> self.recording)
> 
> .
> .
> .
> 
>         # Data recording control
>         buttonbox =
> wx.BoxSizer(wx.HORIZONTAL)
>         self.record_control =
> form.button_with_callback(self.panel,
>              
> label="Recording Data: Off         
>                
>                
>                
>          ",
>              
> callback=self.toggle_recording)
> 
>        
> buttonbox.Add(self.record_control, 0, wx.CENTER)
> 
> .
> .
> .
> 
>     #
>     # Turn recording on/off
>     # Called-back by "Recording" button
>     #
>     def toggle_recording(self):
>         # Pick up localtime, for
> generating filenames
>         timestamp = time.localtime()
> 
>         # Generate filenames for both
> data and header file
>         filename =
> "%04d_%02d_%02d_%02d:%02d:%02d.dat" % (timestamp.tm_year,
> timestamp.tm_mon,
>         timestamp.tm_mday,
> timestamp.tm_hour, timestamp.tm_min,timestamp.tm_sec)
> 
>         # Current recording?  Flip
> state
>         if (self.recording_state ==
> True):
>           self.recording_state =
> False
>          
> self.record_control.SetLabel("Recording Data: Off 
>                
>                
>                
>   ")
>           self.recording.close()
>         # Not recording?
>         else:
>           self.recording_state =
> True
>          
> self.record_control.SetLabel("Recording Data to:
> "+filename)
> 
>           # Cause gr_file_sink
> object to accept new filename
>           #   note
> use of self.prefix--filename prefix from
>          
> #   command line (defaults to ./)
>           #
>           self.recording.open
> (self.prefix+filename)
> 
> 
> Thanks!
> eric
> 
Following up on this, I found this site that had some useful 
suggestions:http://www.oz9aec.net/index.php/gnu-radio/grc-examples

A grc example is provided that implements a dynamic time stamp, but NOT a 
button to control it.  So I am trying to use a Variable Chooser to select 
between "/dev/null" and the filename that is based on the time-stamp.  However, 
nothing is generated.  In particular, I have:

A file sink with File: recfile
A Variable with ID prefix with Value "./"
A Variable Chooser with ID: recfile, Default Value: "/dev/null" and 
Choices of "/dev/null" or "prefix + 
datetime.now().strftime("%Y.%m.%d.%H.%M.%S") + ".bin"

I was hoping this would dynamically create a file with the current time stamp 
for the name, but no files are actually being generated.  Could this be and 
issue related to a bug that is described in the link below?

http://lists.gnu.org/archive/html/discuss-gnuradio/2011-01/msg00080.html

If so, will this approach work if I upgrade via git?

Thanks!
eric
> 
> 
>       
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 




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


Re: [Discuss-gnuradio] Yet another kick at the cheap-hardware can

2011-01-20 Thread Marcus D. Leech
I don't know if this is kosher, but has anyone looked at the (vast 
array of) offerings from Comblocks (comblock.com 
)? They sell FPGA IP cores for all of their 
hardware, and it seems like it might be a good match for building a 
basic I/Q acquisition system. Here's a full product list: 
http://comblock.com/product_list.html
The block diagram at the bottom 
of this page gives an idea of how things could work: 
http://comblock.com/com8002.html

-William

The hardware looks somewhat pricey--roughly $1000.00 for a 
receiver+sampler+network  "stack".


But since this is supposed to be an open-source project, I don't think 
licensing FPGA IP is the correct direction, either.


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

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


Re: [Discuss-gnuradio] WBX - only real signal after some time

2011-01-20 Thread Marcus D. Leech
On 01/20/2011 11:40 AM, Ruben Undheim wrote:
> Hello.
>
> I just wondered if anyone else has experienced that the WBX stops
> sending the quadrature component of the complex signal after a while.
> This happens especially if I have sliders for setting the frequencies
> or the gain, and the sliders are slided. (so that a frequency change
> control signal is sent several times successively)
> In an FFT-sink, this is observed as a display mirrored around the base
> frequency.
>
> I have not found any other solution to fix this than to restart the
> whole program every time it happens. This has never happened when
> using the TVRX board.
The TVRX isn't actually a quadrature front-end, so quadrature is
synthesized within the FPGA.

>
> I wonder if this is normal for these daughterboards, and that one just
> has to ensure that they do not get a lot of frequency setting control
> messages successively, or if there is a workaround.
>
I don't think it's normal.  Something definitely wonky.   Are you using
UHD, or "traditional" ??

There was something *similar* in UHD a couple of months back, but it was
for USRP2, so I don't
  think that's it.


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



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


Re: [Discuss-gnuradio] filename using time-stamp in GRC

2011-01-20 Thread Alexandru Csete
On Thu, Jan 20, 2011 at 5:41 PM,   wrote:
>
...
> Following up on this, I found this site that had some useful 
> suggestions:http://www.oz9aec.net/index.php/gnu-radio/grc-examples
>
> A grc example is provided that implements a dynamic time stamp, but NOT a 
> button to control it.  So I am trying to use a Variable Chooser to select 
> between "/dev/null" and the filename that is based on the time-stamp.  
> However, nothing is generated.  In particular, I have:
>
> A file sink with File: recfile
> A Variable with ID prefix with Value "./"
> A Variable Chooser with ID: recfile, Default Value: "/dev/null" and
> Choices of "/dev/null" or "prefix + 
> datetime.now().strftime("%Y.%m.%d.%H.%M.%S") + ".bin"
>
> I was hoping this would dynamically create a file with the current time stamp 
> for the name, but no files are actually being generated.  Could this be and 
> issue related to a bug that is described in the link below?
>
> http://lists.gnu.org/archive/html/discuss-gnuradio/2011-01/msg00080.html
>
> If so, will this approach work if I upgrade via git?
>

Hi Eric,

The problem with this simple example is that the variable containing

"prefix + datetime.now().strftime("%Y.%m.%d.%H.%M.%S") + ".bin"

is evaluated when you start the script, so it will only work for a
single file per execution. I believe it is for the same reason that
you see no file with your modification: The file sink is initialized
with /dev/null as filename and it can not change the file name during
runtime because the required code for "close file, set new file name,
open new file" is not generated by GRC - I am not exactly sure about
this but it should be obvious if you look in the generated code. I
would try to do as Josh said in the other mail, implement the required
code yourself and embed it as a custom block.

Alex

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


Re: [Discuss-gnuradio] Unwanted signal transmitted RFX900

2011-01-20 Thread Nick Foster
On Thu, 2011-01-20 at 12:48 +0100, Paco Quiñoy wrote:
> 
> Hi all,
> 
> Making some tests I have found that my system (USRP + RFX900)
> transmits an important signal (it seems a tone) without any
> application running, just when I plug the power source it transmits
> this unwanted signal. I'm working at the GSM900 downlink frequency
> band (between 935 and 960 MHz) and the signal appears close to the
> upper side of this band, around 959,6 Mhz. 
> 
> My system makes an spectrum sensing for that band and it locates the
> present signals, so it produces an error because it detects this
> undesired signal generated by itself. Any idea of the problem? Any
> solution?

Paco,

This is likely to be the 15th harmonic of the USRP's 64MHz sample clock
(64e6*15=960e6). It may get better after the USRP is initialized (run
uhd_usrp_probe or any other application after power-up). The AD9862
tends to come up in a weird state.

--n

> 
> Thanks!
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio



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


Re: [Discuss-gnuradio] GNURadio is disappointing [was: Greeting and a question]

2011-01-20 Thread Brian Padalino
I changed the subject to better match the tone of the email.

On Thu, Jan 20, 2011 at 11:12 AM, Sanjay Singh
 wrote:
> Hi all,
>
> Am disappointed with the way GNURadio is getting into.
>
> I see all the discussion around is to promote the products of Ettus
> Research.
>
> Agreed!. Great work from Ettus Research.
>
> But there are many boards available which are far better in capability vs
> price. I don't want to mention them here to deviate the concern.
>
> During the market for USRP1, no one in the forum focused discussion on
> embedded platform. When queries regarding any such embedded platform was
> posted, there were lot of quotes saying GNURadio is focused on developing
> SDR framework based on Desktop based solution. With Ettus Research coming
> out with USRP E100, everyone on is bouncing on embedded platform.
>
> I wonder; Is GNURadio biased with Ettus Reserch ?. My obvious understanding
> is NO!.
>
> Its the community of people driving Ettus products into market. The
> potential of doing so is to make money. Either way, Ettus Research is now
> part of National Instruments and may be now GNURadio be delinked with Ettus
> Research for being open source. There are many people who can contribute low
> cost open source solutions.
>
> Initially, all the Hardware and software was part of GNURadio. All the files
> was part of free source available to download and use. In around a year or
> so all the files from GNURadio were moved out separating hardware and
> software. All the hardware related files were not available after this. Why
> so, no one knows.
>
> The boards when purchased from Ettus Research it was under terms and
> conditions as free open source schematics for motherboard and free open
> source schematics and pcb files.
>
> Its time now for the community of people interested in building free open
> source platform including both software and Hardware to come out with an
> complete open source low cost solution.
>
> S---

I need to borrow your soapbox.

This e-mail infuriates me.  If you thought you bought a motherboard
from Ettus under the terms that you were getting schematics and PCB
files and blah blah blah, fine.  If you didn't get them, point to the
line item on the receipt or the clause in the contract and take it up
with Ettus.

Next - the general tone of GNU Radio seems to be biased towards Ettus
only due to the fact that he, Josh and a whole slew of other people
worked damned hard to not only develop their hardware, but make sure
it was compatible with GNU Radio.

Let me repeat that.

Matt, Josh, and the rest of the people at Ettus Research did damn near
ALL the legwork - software and hardware - to make it compatible with
GNU Radio so you can buy something, plug it in and make it work.
Moreover, they field support questions on an open forum for free.  To
dismiss this fact is grossly inappropriate.

On that note, I have put together a simple list of things for people
to do if they feel they want to get out of this Ettus Research
totalitarian dictatorship that is GNU Radio:

1) Create your own RF front end boards
2) Create your own digital/baseband board
3) Write all the software for board in step (2) to control all the
boards you create in step (1)
4) Write all the host side software to interface software written
in step (3) with GNU Radio
5) Contribute all previous work to GNU Radio
6) Stop complaining*

*NOTE: Steps 1-5 are optional.

I am a massive proponent of making some 100% fully open SDR hardware
that serves the low cost/cheap and
easily-modifiable-for-my-specific-purpose market.

Like I said in my original e-mail, stop asking and stop the rhetoric.
If you want to dethrone Ettus from the monopoly he has on the GNU
Radio hardware scene, you just need to do something.  GNU Radio is
open source.  Make your board and contribute your patches.

In other words, do some work if you don't like the current state of
things.  This community is driven by the people on this list.  If you
don't like something about it, you need to have the drive to change
it.  Demonizing Ettus Research is childish.  If anything, look at
their past and draw inspiration from it.

I look forward to seeing your patches in GNU Radio.

Thanks for the soapbox.

Brian

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


Re: [Discuss-gnuradio] filename using time-stamp in GRC

2011-01-20 Thread ematlis


--- On Thu, 1/20/11, Alexandru Csete  wrote:

> From: Alexandru Csete 
> Subject: Re: [Discuss-gnuradio] filename using time-stamp in GRC
> To: discuss-gnuradio@gnu.org
> Date: Thursday, January 20, 2011, 11:41 AM
> On Thu, Jan 20, 2011 at 5:41
> PM,  
> wrote:
> >
> ...
> > Following up on this, I found this site that had some
> useful suggestions:http://www.oz9aec.net/index.php/gnu-radio/grc-examples
> >
> > A grc example is provided that implements a dynamic
> time stamp, but NOT a button to control it.  So I am trying
> to use a Variable Chooser to select between "/dev/null" and
> the filename that is based on the time-stamp.  However,
> nothing is generated.  In particular, I have:
> >
> > A file sink with File: recfile
> > A Variable with ID prefix with Value "./"
> > A Variable Chooser with ID: recfile, Default Value:
> "/dev/null" and
> > Choices of "/dev/null" or "prefix +
> datetime.now().strftime("%Y.%m.%d.%H.%M.%S") + ".bin"
> >
> > I was hoping this would dynamically create a file with
> the current time stamp for the name, but no files are
> actually being generated.  Could this be and issue related
> to a bug that is described in the link below?
> >
> > http://lists.gnu.org/archive/html/discuss-gnuradio/2011-01/msg00080.html
> >
> > If so, will this approach work if I upgrade via git?
> >
> 
> Hi Eric,
> 
> The problem with this simple example is that the variable
> containing
> 
> "prefix + datetime.now().strftime("%Y.%m.%d.%H.%M.%S") +
> ".bin"
> 
> is evaluated when you start the script, so it will only
> work for a
> single file per execution. I believe it is for the same
> reason that
> you see no file with your modification: The file sink is
> initialized
> with /dev/null as filename and it can not change the file
> name during
> runtime because the required code for "close file, set new
> file name,
> open new file" is not generated by GRC - I am not exactly
> sure about
> this but it should be obvious if you look in the generated
> code. I
> would try to do as Josh said in the other mail, implement
> the required
> code yourself and embed it as a custom block.
> 
> Alex
> 
Thank you all.

Eric

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




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


Re: [Discuss-gnuradio] GNURadio is disappointing [was: Greeting and a question]

2011-01-20 Thread Sanjay Singh
Hi all,

To be specific to concern

   1) Create your own RF front end boards
> putting mixer and LO is a handy breadboard work.. tryout some good
examples from Analog Devices and TI. To get additional gains put LNA or PA
in series. Learn basic hardware designs.

   2) Create your own digital/baseband board
> Check out many thesis work who have developed demonstrating platforms.
Adding to commercial front, check SP601/605 from Avnet. Check for the prices
for sure!. Also check Spartan 3A 1800 DSP from Xilinx.

   3) Write all the software for board in step (2) to control all the
boards you create in step (1)
> Not required. All the development boards are platform specific and the
board developer supports BSP(Board support package). If you are building
your board, you need to develop your own BSP. All the development board
comes with BSP. A mere DMA transfers between PC and board is a 4 weeks of
development activity.

   4) Write all the host side software to interface software written
in step (3) with GNU Radio
> Platform independent drivers already address the issue.

   5) Contribute all previous work to GNU Radio
> No one says its personal development after posting at open source
community developers

   6) Stop complaining*
> No one complains unless there is deviation against addressed.


The capability and contribution you are talking about cannot be patchy work.
Patchy work is needed to fix design bugs. Open source community would be
interested to have proper solution rather patches.

S--




On Fri, Jan 21, 2011 at 12:12 AM, Brian Padalino wrote:

> I changed the subject to better match the tone of the email.
>
> On Thu, Jan 20, 2011 at 11:12 AM, Sanjay Singh
>  wrote:
> > Hi all,
> >
> > Am disappointed with the way GNURadio is getting into.
> >
> > I see all the discussion around is to promote the products of Ettus
> > Research.
> >
> > Agreed!. Great work from Ettus Research.
> >
> > But there are many boards available which are far better in capability vs
> > price. I don't want to mention them here to deviate the concern.
> >
> > During the market for USRP1, no one in the forum focused discussion on
> > embedded platform. When queries regarding any such embedded platform was
> > posted, there were lot of quotes saying GNURadio is focused on developing
> > SDR framework based on Desktop based solution. With Ettus Research coming
> > out with USRP E100, everyone on is bouncing on embedded platform.
> >
> > I wonder; Is GNURadio biased with Ettus Reserch ?. My obvious
> understanding
> > is NO!.
> >
> > Its the community of people driving Ettus products into market. The
> > potential of doing so is to make money. Either way, Ettus Research is now
> > part of National Instruments and may be now GNURadio be delinked with
> Ettus
> > Research for being open source. There are many people who can contribute
> low
> > cost open source solutions.
> >
> > Initially, all the Hardware and software was part of GNURadio. All the
> files
> > was part of free source available to download and use. In around a year
> or
> > so all the files from GNURadio were moved out separating hardware and
> > software. All the hardware related files were not available after this.
> Why
> > so, no one knows.
> >
> > The boards when purchased from Ettus Research it was under terms and
> > conditions as free open source schematics for motherboard and free open
> > source schematics and pcb files.
> >
> > Its time now for the community of people interested in building free open
> > source platform including both software and Hardware to come out with an
> > complete open source low cost solution.
> >
> > S---
>
> I need to borrow your soapbox.
>
> This e-mail infuriates me.  If you thought you bought a motherboard
> from Ettus under the terms that you were getting schematics and PCB
> files and blah blah blah, fine.  If you didn't get them, point to the
> line item on the receipt or the clause in the contract and take it up
> with Ettus.
>
> Next - the general tone of GNU Radio seems to be biased towards Ettus
> only due to the fact that he, Josh and a whole slew of other people
> worked damned hard to not only develop their hardware, but make sure
> it was compatible with GNU Radio.
>
> Let me repeat that.
>
> Matt, Josh, and the rest of the people at Ettus Research did damn near
> ALL the legwork - software and hardware - to make it compatible with
> GNU Radio so you can buy something, plug it in and make it work.
> Moreover, they field support questions on an open forum for free.  To
> dismiss this fact is grossly inappropriate.
>
> On that note, I have put together a simple list of things for people
> to do if they feel they want to get out of this Ettus Research
> totalitarian dictatorship that is GNU Radio:
>
>1) Create your own RF front end boards
>2) Create your own digital/baseband board
>3) Write all the software for board in step (2) to control all the
> boards you create in step (1)
>4) Write all the ho

Re: [Discuss-gnuradio] E100 Suitability for Space Applications

2011-01-20 Thread Matt Ettus

On 01/19/2011 07:56 AM, Ed Criscuolo wrote:

Matt,

I'm considering the E100 for use with GnuRadio/UHD
aboard a small spacecraft, and I have a few of questions:


We definitely did not design with space applications in mind.



1. What's the power drain? Watt-hours are always at a
premium aboard a small spacecraft.


The E100 itself draws about 6-9 Watts.  The daughterboard will also draw 
power, up to as much as an additional 6 or 7 watts depending on the board.




2. Are there any vacuum-sensitive components? For example,
electrolytic capacitors are no good (they dry out or rupture)
but tantalum's are ok.


No electrolytics on there.  There are 4 crystal oscillators which may or 
may not have vacuum issues.




3. Is cooling an issue? Air-cooled heatsinks don't work in
vacuum, and have to be replaced with conduction cooling.


We have done no testing of cooling in a vacuum, so you are really on 
your own here.



4. Any Lithium batteries? They are considered hazardous for
space and require special provisions or removal.


There is a coin cell battery backup for the real time clock, but that 
can be removed.



5. Without writing any FPGA or DSP code, what's the ballpark
sample rate that the ARM can keep up with?


It largely depends on what you want to do with those samples, but you 
should figure on 4-5 MS/s.


Matt

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


Re: [Discuss-gnuradio] WBX - only real signal after some time

2011-01-20 Thread Ruben Undheim
Thanks

I am using the traditional driver. Maybe I can try to use another computer
or to put the board in the other slot,
and see if the problem remains the same.

Ruben

2011/1/20 Marcus D. Leech 

> On 01/20/2011 11:40 AM, Ruben Undheim wrote:
> > Hello.
> >
> > I just wondered if anyone else has experienced that the WBX stops
> > sending the quadrature component of the complex signal after a while.
> > This happens especially if I have sliders for setting the frequencies
> > or the gain, and the sliders are slided. (so that a frequency change
> > control signal is sent several times successively)
> > In an FFT-sink, this is observed as a display mirrored around the base
> > frequency.
> >
> > I have not found any other solution to fix this than to restart the
> > whole program every time it happens. This has never happened when
> > using the TVRX board.
> The TVRX isn't actually a quadrature front-end, so quadrature is
> synthesized within the FPGA.
>
> >
> > I wonder if this is normal for these daughterboards, and that one just
> > has to ensure that they do not get a lot of frequency setting control
> > messages successively, or if there is a workaround.
> >
> I don't think it's normal.  Something definitely wonky.   Are you using
> UHD, or "traditional" ??
>
> There was something *similar* in UHD a couple of months back, but it was
> for USRP2, so I don't
>  think that's it.
>
>
> --
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] GNURadio is disappointing [was: Greeting and a question]

2011-01-20 Thread Marcus D. Leech

On 01/20/2011 02:10 PM, Sanjay Singh wrote:

Hi all,

To be specific to concern


   2) Create your own digital/baseband board
> Check out many thesis work who have developed demonstrating 
platforms. Adding to commercial front, check SP601/605 from Avnet. 
Check for the prices for sure!. Also check Spartan 3A 1800 DSP from 
Xilinx.


   3) Write all the software for board in step (2) to control all the
boards you create in step (1)
> Not required. All the development boards are platform specific and 
the board developer supports BSP(Board support package). If you are 
building your board, you need to develop your own BSP. All the 
development board comes with BSP. A mere DMA transfers between PC and 
board is a 4 weeks of development activity.
So, respectfully, you're full of crap, Sanjay.  No "BSP" is going to 
automatically know how to do all the functions we want to do:


   o Interface with whatever RF hardware is developed above
   o Do the required DDC and CIC Decimation, and whatever else *this 
specific application requires*.
   o Send data over the host-interface, *in the required formats, using 
the required protocols*


There's no magic "FPGA Fairy" that somehow intuits exactly what you want 
your *application* to do, and do it for you,

  whether you use an off-the-shelf FPGA card, or roll your own.

Certainly, a BSP can *help* with basic functionality, and provide 
libraries to make it easier to integrate your application, whatever
  that application may be, but the BSP doesn't construct that 
application all by itself.  Some work, quite significant, is required

  to *construct* your own application.



   4) Write all the host side software to interface software written
in step (3) with GNU Radio
> Platform independent drivers already address the issue.
Right.  Because Xilinx/Altera/Digilent/whoever has already written 
drivers to interface to Gnu Radio, but they're
  selfishly withholding that information from public view?  How 
churlish of them.





   5) Contribute all previous work to GNU Radio
> No one says its personal development after posting at open source 
community developers


   6) Stop complaining*
> No one complains unless there is deviation against addressed.



I have no idea what you're talking about.

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



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


Re: [Discuss-gnuradio] About clock rate of USRP E100

2011-01-20 Thread Josh Blum

> Thanks a lot for your help. Could you explain how to slow down the FPGA/ADC
> rate?  How should we modify the firmware? Which part of the code should we
> look into?  Thanks!
> 
> 

This is a host code modification.
see the clock_ctrl.cpp in host/lib/usrp/usrp_e100/

http://code.ettus.com/redmine/ettus/projects/uhd/repository/revisions/master/entry/host/lib/usrp/usrp_e100/clock_ctrl.cpp

You will want to manipulate codec clock.

-Josh

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


Re: [Discuss-gnuradio] constellation object

2011-01-20 Thread Ben Reynwar
On Thu, Jan 20, 2011 at 1:46 AM, Martin Braun  wrote:
> On Wed, Jan 19, 2011 at 11:55:30AM -0700, Ben Reynwar wrote:
>> I'm new to all this, so I don't have a good handle on soft versus hard
>> decision making.  My understanding is that a hard decision maker
>> simply returns the symbol value, and a soft decision maker would
>> return probabilities for various symbols values.  Then this
>> probabilistic information would be interpreted by the decoder which
>> would make the hard decision for sets of symbols simultaneously.  I
>> don't understand what receiver_cf is doing if it returning a stream of
>> floats.
>
> You've got that right: a soft decider doesn't really decide, but rather
> gives a value how good the estimate is. Say you have a binary output,
> 1 and -1. A soft decider can also give any value in between. If you get
> a 0, then the soft decider really has no clue what was actually
> transmitted and instead of guessing a binary value, it relays this
> uncertainty.
> One place this is really important is the channel decoding.
>

That makes sense.  What kind of values would you output when you have more
than 2 symbols?  Would you just give the distances to the closest n points?

>> On a related note, I've read that the minimum euclidean distance
>> minimizes the chance of error if you have white gaussian noise.  Is
>> this always a sensible assumption or are there practical situations in
>> which a different measure would be better?  If not, then the distance
>> could be used as a proxy for probability.  If others measures are
>> sometimes better, then it would be nice to keep things more general.
>
> Just a couple of euro-cents I'd like to add:
> - White noise is a perfectly valid assumption. In most cases, your noise
>  is WGN-ish anyway. If it isn't, then the constellation demodulator is
>  not the right place to handle it, you'd use some kind of pre-whitening
>  filter a priori.

Good to know.

> - I'd say if you have to implement a soft- and hard-decider for each
>  constellation anyway, you're general enough. With the aforementioned
>  point, this means the hard decider is sіmply always the minimum
>  euclidean distance, as you said already.
> - After having a quick peek at your code, I wasn't quite sure if you've
>  thought of differential PSKs?


I've just implemented it for PSK but have to tidy it up a bit before
pushing it to my github repo.  Works fine for differential PSK,
although I had to put map_bb blocks into the generic blocks to get
gray coding working.

>

> All that aside, I think this is a good approach. GNU Radio currently has
> a lot of fantastic DЅP code; what I miss is more structure, and I'm glad
> to hear about the plans to refactor the digital stuff.
>
> Cheers,
> MB
>
> --
> Karlsruhe Institute of Technology (KIT)
> Communications Engineering Lab (CEL)
>
> Dipl.-Ing. Martin Braun
> Research Associate
>
> Kaiserstraße 12
> Building 05.01
> 76131 Karlsruhe
>
> Phone: +49 721 608-43790
> Fax: +49 721 608-46071
> www.cel.kit.edu
>
> KIT -- University of the State of Baden-Württemberg and
> National Laboratory of the Helmholtz Association
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>

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


Re: [Discuss-gnuradio] GNURadio is disappointing [was: Greeting and a question]

2011-01-20 Thread Elvis Dowson
Hi Tom & Matt,

Begin forwarded message:

> From: "Marcus D. Leech" 
>> 
> So, respectfully, you're full of crap, Sanjay.  No "BSP" is going to 
> automatically know how to do all the functions we want to do:

Someone ought to moderate this list. I for one find Marcus annoying. He 
mentioned that he's employed part time by Ettus Research. He should be told to 
tone down. It just takes a few guys like Marcus to put people off. 

If there are people on the list that don't like Ettus Research or the way Gnu 
Radio is running, take them off the list. At least it will keep things focussed 
in the right direction. 

As for people like Marcus, they should be told to behave politely to other 
members on the list.

Elvis Dowson


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


Re: [Discuss-gnuradio] Yet another kick at the cheap-hardware can

2011-01-20 Thread Moeller
On 20.01.2011 16:16, William Cox wrote:
> I don't know if this is kosher, but has anyone looked at the (vast array of) 
> offerings from Comblocks (comblock.com )? They sell
> FPGA IP cores for all of their hardware, and it seems like it might be a good 
> match for building a basic I/Q acquisition system. Here's a full product
> list: http://comblock.com/product_list.html

Not really.
Open Projects like GNU need open IP like in:

http://en.wikipedia.org/wiki/OpenCores

There is Ethernet controller code (up to GBit/s), USB2 code,
OpenRISC, PIC, Microcontrollers etc.

The DSP section has special signal processing blocks,
like this project of a hardware FFT processor:
http://opencores.org/project,pipelined_fft_128
What about a Gnuradio emitting FFT samples instead of time domain samples,
for applications like spectrum analyzers or cognitive radio monitoring modes?

Gnuradio would be a good software/hardware platform for further development
of OpenCores. I like the idea. The SDR section is still empty
http://opencores.org/project,software_defined_radio
Why not contributing SDR code to OpenCores?

Btw, USRP2 is also using OpenCores verilog code in the FPGA directory.

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


Re: [Discuss-gnuradio] Yet another kick at the cheap-hardware can

2011-01-20 Thread Moeller
On 20.01.2011 00:23, Marcus D. Leech wrote:

> If the answer to the above is "yes", then the next question is:  is
> there a community of interested
>   volunteers to bring the project to fruition?  Such an interested
> community would involve:

I'm interested in developing a SDR teaching platform, especially
for introducing electronics to children. I tried it with simple
logic circuits and blinking LED, a simple FM radio (surely no Hifi).
But kids today grow up with MP3 players, computers and other high tech
electronics. They expect electronics to be more fascinating.
So, what's more attractive than stupid blinking LED experiments?
The Gnuradio RADAR experiment? Looking into the wide radio spectrum?
Visualizing radio emissions of electronic devices, the microwave oven,
car key, mobile phone, ... ?
As a child, I was very fascinated with my analogous oscilloscope,
analyzing and repairing all kind of devices. I think nowadays, after
so much progess in technology, it should be a device like Gnuradio.

>  o High-level hardware design

I'm thinking of a scope frontend, with switchable voltage levels.
Maybe my old scope schematics (was an appendix to the user manual)
could give inspiration. At least I would use a circuit for overvoltage
protection and an attenuator (in front of the first LNA).
It does not have to be integrated on the PCB, possibly only an
additional box in front of the antenna input.
I don't mind if there is no DC coupling.
The power levels could be calibrated in software.

>  o Detailed schematic capture and PCB layout

I installed KiCad (http://kicad.sourceforge.net/).
My first impression was very positive, especially with
the FPGA example project.

>  o FPGA firmware design

used it for glue logic circuits before, in VHDL ...

>  o Host-interface (FX2?) firmware design
>  o Host driver software design and implementation

I suppose there is also public domain software available.

>  o Small-scale financial investment for initial PCBs, components, etc

I don't mind if a board of $100 explodes during debugging.
As I child I burned many semiconductor devices.
Our local PCB manufacturer asks 50€ for prototype boards. I could try with one.

> Once such a board works, then someone needs to be found to distribute
> either kits or finished product.

There are electronics and amateur radio magazines that distribute such kits.
Up to now they offer only simple soundcard-based solutions. I'm sure to attract
more readers they will be happy to publish articles and distribute kits
with new innovative designs.

In development countries it could be adapted to the local price level.

> Something that vaguely compares to this effort is the FunCube Dongle,
> which is a quadrature
>   receiver covering 64MHz to 1.7GHz, but with 96KHz host-side bandwidth.
>  That project is selling fully-built units for about USD 170.00.

Sold out in a few minutes after starting the offer.
Apparently there is a huge market for cheap SDR devices.

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


[Discuss-gnuradio] NanoSail-D turns out isn't lost!

2011-01-20 Thread Marcus D. Leech
If you're in a position to listen for the beacon packets of NanoSail-D, 
some of the details are here:


http://nanosaild.engr.scu.edu/dashboard.htm

Wish my SBRAC dish was fully operational.  I'd actually be able to 
*track* it--I've got 400MHz feeds, and

  a WBX-based receive chain.  So much coolness, so little time :-(

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



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


Re: [Discuss-gnuradio] NanoSail-D turns out isn't lost!

2011-01-20 Thread Alexandru Csete
On Fri, Jan 21, 2011 at 2:03 AM, Marcus D. Leech  wrote:
> If you're in a position to listen for the beacon packets of NanoSail-D, some
> of the details are here:
>
> http://nanosaild.engr.scu.edu/dashboard.htm
>
> Wish my SBRAC dish was fully operational.  I'd actually be able to *track*
> it--I've got 400MHz feeds, and
>  a WBX-based receive chain.  So much coolness, so little time :-(

I tried earlier today with a handheld Arrow II yagi connected directly
to WBX. I could hear it but it was too weak to decode. A bigger yagi
should give sufficient signal.
In case you receive, it is very easy to decode the telemetry. It uses
1200 bps AFSK FM modulating the carrier, so a simple NBFM receiver and
the audio fed to e.g. multimon
(http://www.baycom.org/~tom/ham/linux/multimon.html) works. Decoded
telemetry can be submitted to the ops team at
http://beacon.engr.scu.edu/Submission.aspx

Have fun!

Alex

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


Re: [Discuss-gnuradio] hi all, can I use one RX receive a wideband signal and then seperate it to many narrowband signals

2011-01-20 Thread James Jordan
Hi Tom,
This is very old topic. I have read a DSP book. But I find that I still not
very understand channelizer.
Why in channelizer use low pass filter, in my imagine channelizer will use
band pass filter to filter each
channel like that: 600Mhz baseband signal have 4 channel each channel have
100Khz bandwidth.
so the channel freq is: 599.8Mhz 599.9Mhz 600Mhz 600.1Mhz. So I need 4
bandpass filter to filter each
channel but actually the channelizer use lowpass filter, so why?

Thanks!

On Thu, Dec 23, 2010 at 10:16 PM, Tom Rondeau wrote:

> On Thu, Dec 23, 2010 at 3:53 AM, James Jordan
>  wrote:
> > Thanks Tom.
> > if I really don't know how pfb_channelizer_ccf and pfb_decimator_ccf do,
> but
> > they seem
> > use the same principle. And how to set the taps?
>
>
> Yes, they are based on the same principle, but the decimator just
> extracts the 1 channel while the channelizer produces all channels.
>
> To create the taps, you want to build a prototype filter that will
> have the bandwidth of the channelized signals at the input sampling
> rate. So if the input to the channelizer is fs and the bandwidth of
> each channel is B, you can build the taps with:
> taps = gr.firdes.low_pass_2(1, fs, B/2, B/10, 80)
>
> The "B/10" is the transition width, which you can make as tight as you
> need to, this is just a random guess right now. The 80 is the stopband
> attenuation. This should make a rather long filter, then each channel
> uses a filter that is len(taps)/N.
>
> In the examples directory, you can see how this is done in
> pfb/cahnnelize.py and pfb/decimate.py.
>
> Tom
>
>
>
> > On Thu, Dec 23, 2010 at 2:49 PM, Tom Rondeau 
> wrote:
> >>
> >> On Thu, Dec 23, 2010 at 1:19 AM, James Jordan
> >>  wrote:
> >> > Hi Martin,
> >> > pfb_channelizer_ccf will seperate all channels, But I dont need each
> >> > channel.
> >> > I only need the channel I am interested in. Seperating all channels
> will
> >> > eat
> >> > a lot of CPU resource.
> >>
> >>
> >> Not really. It's a very efficient algorithm and won't cost you that
> much.
> >>
> >>
> >> > I have check pfb_channelizer_ccf source, it finally use fftw to
> process
> >> > channelizer.
> >> > So can I directly use fftw to do my work.
> >>
> >> Not quite. The PFB channelizer uses a filterbank where each filter is
> >> specifically generated with a phase relation. The FFT part isn't doing
> >> exactly what you expect it's doing. We'd have to go through the math,
> >> though.
> >>
> >> If you are looking to just get a single channel out, then use the
> >> pfb_decimator_ccf(N, taps, channel) to split the bandwidth into "N"
> >> channels, using filter taps "taps," and you can specify which channel
> >> you want to take by specifying the "channel." Here's the way to
> >> translate the "channel" into the physical Nyquist zone you are looking
> >> for N=7 (hopefully this format survives):
> >>
> >> Channel:  456  0   1   2   3
> >> Frequency: -3B  |  -2B  |  -1B  |  0  |   2B  |  2B  |  3B
> >>
> >> Tom
> >>
> >>
> >> > On Tue, Dec 21, 2010 at 6:19 PM, Martin Braun 
> >> > wrote:
> >> >>
> >> >> On Tue, Dec 21, 2010 at 06:02:44PM +0800, James Jordan wrote:
> >> >> > Hi all, I need to receive many narrowband signals, but usrp hard
> ware
> >> >> > only
> >> >> > provide 4 RX,
> >> >> > so I need to receive more than one narrowband signals per RX. Is my
> >> >> > idea
> >> >> > possible?
> >> >> > I dont want to use more than one usrp to achieve that, anyway which
> >> >> > will
> >> >> > be an
> >> >> > option if my first idea can't work.
> >> >>
> >> >> If your total bandwidth (sum of all bandwidths) does not exceed a
> >> >> couple
> >> >> of MHz, you can use the polyphase channelizer (pfb_channelizer_ccf).
> >> >> The result will be an equally spaced set of narrowband channels.
> >> >>
> >> >> Happy DSP'ing,
> >> >> MB
> >> >>
> >> >> --
> >> >> Karlsruhe Institute of Technology (KIT)
> >> >> Communications Engineering Lab (CEL)
> >> >>
> >> >> Dipl.-Ing. Martin Braun
> >> >> Research Associate
> >> >>
> >> >> Kaiserstraße 12
> >> >> Building 05.01
> >> >> 76131 Karlsruhe
> >> >>
> >> >> Phone: +49 721 608-3790
> >> >> Fax: +49 721 608-6071
> >> >> www.cel.kit.edu
> >> >>
> >> >> KIT -- University of the State of Baden-Württemberg and
> >> >> National Laboratory of the Helmholtz Association
> >> >>
> >> >>
> >> >> ___
> >> >> Discuss-gnuradio mailing list
> >> >> Discuss-gnuradio@gnu.org
> >> >> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >> >>
> >> >
> >> >
> >> > ___
> >> > Discuss-gnuradio mailing list
> >> > Discuss-gnuradio@gnu.org
> >> > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >> >
> >> >
> >
> >
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] GNURadio is disappointing [was: Greeting and a question]

2011-01-20 Thread Sanjay Singh
Its not about talking high. Its community of people trying hard to press
Ettus Research products. Putting people down is not the motto of GNURadio.

Regrading putting off from the list: Discussion is on for open source
platform. This is GNURadio platform. Here discussions are open for Ettus
Research products and any other hardware product which can be used with
GNURadio.

Is GNURadio also owned by Ettus Research ?.

Regarding your concern on keeping things focused;
Things on GNURadio are not focused. That's the concern. When.open source
platform is the focus then everyone has the freedom to discuss open platform
solution rather than promoting specific products for commercial needs.
Regrading your comment
"people on the list that don't like Ettus Research or the way Gnu Radio is
running, take them off the list "
Is that only Ettus Research based products needs to be discussed ?. I
suggest you reconsider your statement.

On Fri, Jan 21, 2011 at 2:25 AM, Elvis Dowson  wrote:

> Hi Tom & Matt,
>
> Begin forwarded message:
>
> > From: "Marcus D. Leech" 
> >>
> > So, respectfully, you're full of crap, Sanjay.  No "BSP" is going to
> automatically know how to do all the functions we want to do:
>
> Someone ought to moderate this list. I for one find Marcus annoying. He
> mentioned that he's employed part time by Ettus Research. He should be told
> to tone down. It just takes a few guys like Marcus to put people off.
>
> If there are people on the list that don't like Ettus Research or the way
> Gnu Radio is running, take them off the list. At least it will keep things
> focussed in the right direction.
>
> As for people like Marcus, they should be told to behave politely to other
> members on the list.
>
> Elvis Dowson
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] hi all, can I use one RX receive a wideband signal and then seperate it to many narrowband signals

2011-01-20 Thread Marcus D. Leech
On 01/20/2011 09:42 PM, James Jordan wrote:
> Hi Tom,
> This is very old topic. I have read a DSP book. But I find that I
> still not very understand channelizer.
> Why in channelizer use low pass filter, in my imagine channelizer will
> use band pass filter to filter each
> channel like that: 600Mhz baseband signal have 4 channel each channel
> have 100Khz bandwidth.
> so the channel freq is: 599.8Mhz 599.9Mhz 600Mhz 600.1Mhz. So I need 4
> bandpass filter to filter each
> channel but actually the channelizer use lowpass filter, so why?
>
>
I know you've asked Tom, but he's on the road.  I haven't looked at the
Gnu Radio channelizer, but one
  way to implement a channelizer is to convert all the signals to
baseband, then low-pass filter.That
  way, all channels are at baseband when you're done.

Does that make sense?




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



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


Re: [Discuss-gnuradio] hi all, can I use one RX receive a wideband signal and then seperate it to many narrowband signals

2011-01-20 Thread James Jordan
Marcus, Thanks for reply.
That is make sense, so the point become how to convert the signal to
baseband.

On Fri, Jan 21, 2011 at 11:11 AM, Marcus D. Leech  wrote:

> On 01/20/2011 09:42 PM, James Jordan wrote:
> > Hi Tom,
> > This is very old topic. I have read a DSP book. But I find that I
> > still not very understand channelizer.
> > Why in channelizer use low pass filter, in my imagine channelizer will
> > use band pass filter to filter each
> > channel like that: 600Mhz baseband signal have 4 channel each channel
> > have 100Khz bandwidth.
> > so the channel freq is: 599.8Mhz 599.9Mhz 600Mhz 600.1Mhz. So I need 4
> > bandpass filter to filter each
> > channel but actually the channelizer use lowpass filter, so why?
> >
> >
> I know you've asked Tom, but he's on the road.  I haven't looked at the
> Gnu Radio channelizer, but one
>  way to implement a channelizer is to convert all the signals to
> baseband, then low-pass filter.That
>  way, all channels are at baseband when you're done.
>
> Does that make sense?
>
>
>
>
> --
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] Yet another kick at the cheap-hardware can

2011-01-20 Thread James Jordan
Hi Marcus,
In your design there is only a single RX. I think it is better to build an
expandable board which can expand 2 RX 3 RX...
That will only introduce a little more cost but will meet much more people's
need.

On Thu, Jan 20, 2011 at 11:39 AM, James Jordan
wrote:

> Hi Marcus,
> Who works on this project now?
> Why choose USB as the interface to host. The USB interface became the
> bandwidth bottleneck
> in USRP1, so why use network interface?
>
>
> On Thu, Jan 20, 2011 at 7:23 AM, Marcus D. Leech wrote:
>
>>
>> http://www.sbrac.org/files/digital_receiver_cheap.pdf
>>
>> This has everything in one place--commit to a single host I/O, and go
>> cheaper as a result.
>>
>> The estimated BOM cost for this, including PCB would be under $100.00.
>>
>> If you sacrifice very-fine tunability, then you don't need a DDC in the
>> FPGA, and only need
>>  a CIC decimator chain, and you only need Rx logic in the FPGA, so you
>> can get away with
>>  the smaller EP1C6 FPGA.  There's a 9K-LE Xilinx Spartan-6 which is
>> marginally cheaper
>>  ($16.44 vs $17.50) than the Altera, but only available in larger
>> quantities from Digikey.
>>  Also, I think the Altera toolchain is cheaper (free??) -- I dunno, I'm
>> not an FPGA guy.
>>
>> Note the use of ultra-cheap 8-bit ADCs.  This design isn't going to win
>> any awards for
>>  dynamic range, but it helps keep the BOM cost down, and as someone
>> else observed, you
>>  get processing gain every time you reduce the bandwidth.  So at 5MHz
>> bandwidth, you've
>>  added a couple of effective bits.  For the types of wide-band
>> science-radio experiments
>>  one might want to do with this, a handful of bits is just fine.
>>
>> Now, I want to emphasize again that I have *no interest* in physically
>> producing such a thing,
>>  but I'm always willing to contribute my engineering wisdom, for
>> whatever that's worth.
>>
>> Also, to set a ground rule for future discussions.  If this turns,
>> yet-again, into an Ettus-bashing
>>  fest, I'm dropping out of the thread, and not participating in any
>> further discussions.  Such
>>  nonsense isn't productive, or even fair or reasonable.   Matt and his
>> employees (and part-time
>>  contractors, like me) are good, hard-working people with an excellent
>> product, and who have
>>  **pioneered** reasonably-priced hardware that works well with Gnu Radio.
>>
>> The question I think this discussion can answer is fairly simple:  are
>> there design choices that can
>>  be made, with significant compromises in functionality, that can
>> produce a design that is practically
>>  producible by an open-source hardware community, and will such a
>> device be useful-enough over
>>  the types of hobbiest uses-cases we're interested in.  Further, will
>> such a device meet the
>>  delivered-price goals.
>>
>> If the answer to the above is "yes", then the next question is:  is
>> there a community of interested
>>  volunteers to bring the project to fruition?  Such an interested
>> community would involve:
>>
>> o High-level hardware design
>> o Detailed schematic capture and PCB layout
>> o FPGA firmware design
>> o Host-interface (FX2?) firmware design
>> o Host driver software design and implementation
>> o Small-scale financial investment for initial PCBs, components, etc
>>
>> Once such a board works, then someone needs to be found to distribute
>> either kits or finished product.
>>
>> Something that vaguely compares to this effort is the FunCube Dongle,
>> which is a quadrature
>>  receiver covering 64MHz to 1.7GHz, but with 96KHz host-side bandwidth.
>>  That project is
>>  selling fully-built units for about USD 170.00.
>>
>> --
>> Principal Investigator
>> Shirleys Bay Radio Astronomy Consortium
>> http://www.sbrac.org
>>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] hi all, can I use one RX receive a wideband signal and then seperate it to many narrowband signals

2011-01-20 Thread Marcus D. Leech
On 01/20/2011 10:22 PM, James Jordan wrote:
> Marcus, Thanks for reply.
> That is make sense, so the point become how to convert the signal to
> baseband.
Oh, that's relatively easy--you multiply it with a complex signal at the
same frequency--that's
  exactly how it's done in hardware, and it works equally-well in software.

The Gnu Radio channelizer likely is more sophisticated than that, using
different
  mathematical tricks to improve efficiency, etc.

When you multiply two sinusoids of Xhz and Yhz, you end up with a mixed
sinusoid--
  Xhz+YHz and XHz-Yhz.

In direct-conversion, you mix (multiply) it with a signal of the same
center frequency, and you get
  the baseband frequencies, but since this is baseband, you need to use
complex representation, otherwise
  the + and - frequencies "fold" around each other.


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



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


Re: [Discuss-gnuradio] NanoSail-D turns out isn't lost!

2011-01-20 Thread Marcus D. Leech
On 01/20/2011 08:35 PM, Alexandru Csete wrote:
> I tried earlier today with a handheld Arrow II yagi connected directly
> to WBX. I could hear it but it was too weak to decode. A bigger yagi
> should give sufficient signal.
> In case you receive, it is very easy to decode the telemetry. It uses
> 1200 bps AFSK FM modulating the carrier, so a simple NBFM receiver and
> the audio fed to e.g. multimon
> (http://www.baycom.org/~tom/ham/linux/multimon.html) works. Decoded
> telemetry can be submitted to the ops team at
> http://beacon.engr.scu.edu/Submission.aspx
>
> Have fun!
>
> Alex
>
> ___
>
>   
Yup, I knew it was 1200 AFSK FM.

Good to know you *almost* demodulated it successfully with WBX.

I rather doubt that I'll be able to get to my groups 60ft dish before
the topic becomes
 uninteresting :-(

But I do have a 70cm YAGI in my store-room somewhere, perhaps I shall
dig it out, and
  wait for a pass over my city to see if I can demodulate the signal!

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



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


Re: [Discuss-gnuradio] Showing a time-varying quantity in GNU Radio (with qtgui)

2011-01-20 Thread Minsuk Kang
Thanks, all.
If I have a problem with adding a plotting widget, I'll post further
questions.
:)
--
Minsuk Kang


On Wed, Jan 19, 2011 at 9:01 PM, Tom Rondeau  wrote:

> On Wed, Jan 19, 2011 at 12:08 AM, Minsuk Kang
>  wrote:
> > Dear all,
> > I'm implementing a GUI to show the time-varying wireless channel gain
> with
> > qtgui.
> > To be specific, I want to implement is a history plot.
> > The X-axis is discrete time and the Y-axis is a channel gain.
> > And the plot should be updated (refreshed) every few seconds.
> > ( for example http://qwt.sourceforge.net/cpuplot.png )
> > I've tried with qtgui.sink_f() block.
> > But, the basic option 'plottime' is not appropriate for this purpose.
> > Is there any other way to implement it?
> > Minsuk Kang
>
>
> You will have to add a plotting widget to the qtsink in C++ in
> gr-qtgui/src/lib to do what you want.
>
> Tom
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


[Discuss-gnuradio] How to solve the error of bert in /digital-bert/

2011-01-20 Thread Hanjin Park
Dear all,

>From now on, I tried to estimate BER & SNR value by using bert supported
by gnuradio
in order to get SNR-BER plot for various modulation scheme.

However, when I executed benchmark programs of TX/RX in digital-bert,
SNR value was about 7~8 dB and BER value was about minimum 0.06~0.07
although tx's amplitude is maximum value. I believe that the benchmark
sources has fatal error and I can't use the source for our purpose.

How to solve this problem to get accurate SNR and BER information?
Maybe, Did anyone try to take SNR-BER plot by using gnuradio to other
case, and how?

Please, Help me!!

- Hanjin


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